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WEDNESDAY  18TH  JUNE 


Nstfwrfands  SPIN  (SPIde^  will  extend  a  welcome  to  the  conference. 

Process  bnprovemem  Program  at  the  SEI,  will  then  open  the  conference  on 
;![|te  So(hiroro  Engineering  institute  (SIED:  the  European  Software  Institute  (ESI);  and  the 
Improvement  (ESPQ  Foundation. 

'lil^ilieiKe  btico^  on  both  days  by  Bill  Peterson  and  Chris  Lamer  of  Lloyds  TSB  Croup. 
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C302 

David  Talbot,  European  Commission 

09.55 

Models  of  SPI:  Getting  Beyond  ^  'lies 

C303 
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10.30 

Keynotes  -  Track  A 

Break 

Keynotes -Track  B 

11.00 

C304a 

C304b 

Competence  in  Software  and  Engineering  - 

Sien.  is'  Software  Managing  Culture  Change 
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Cerry  Pasternack,  Citicorp  &  David  Zubrow,  SEI  Michael  Cavanagh  Balmoral  Consulting 

12.30 

LUNCH 

Track  A 

Tracks 

Track  C 

14.00 

C306a 

C306b 

C306c 

Setting  up  SPI  in  a  Multicultural  and 

Capability  Maturity  Model  for  Software, 

Using  SPI  Principles  to  Improve  the 
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How  competitive  is  the 
European  Software  industry? 


Jaap  van  Scheijen 

Director 

Electronics,  Services  &  IT  department 

Ministry  of  Economic  Affairs 


Outline  of  presentation 


•  Position  of  European 
ICT  industries 


•  Embedded  software  in 
The  Netherlands 


•  Conclusions 


Wednesday  IShme 


(C301)S-1 


laip  van  Schciicn, 

Ministry  of  Economic  Affairs,  The  Netherlands 


How  Competitive  is  the 
European  Software  Industry! 
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How  Competitive  U  the 
European  Software  Industry  f 


Requirements  for  the  Application 
of  Embedded  Software 


Importance  and  Need  for  improvement 


Characwristic 

Importance") 

Improve”) 

Reliability 

■4.8 

if.9 

duality 

■4.7 

3.2 

iitandardization 

4.0 

3.1 

Higher  programming  productivity 

3.9 

3.1 

Lower  sw  development  costs 

3.9 

3.2 

Maintainability 

3.8 

2.9 

Compatibility 

3.5 

2.1) 

Reusability 

3.1 

2.7 

*)  Scale  of  1  to  5 


niff 

j  Process  Management  Strategy 

stages  ot  Process  Management 

No  guidelines 

35,2% 

There  are  guides  and  standards 

30,9% 

Strict  guides  and  standards 

5:4% 

Process  is  measured 

5:0%^ 

Process  measured,  improved 

16,9% 

"Don't  know" 

3:6%^ 
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|Mp  van  Schciien, 

Ministry  ol  economic  Attairs,  Th«  NotherUnds 


How  Competitive  i&  the 
European  Software  Industry  t 


Conclusions 


•  European  software  industry  is 
competitive  in  embedded  software 
and  specific  applications 

•  even  in  market-niches  of  packaged 
software 

•  special  care  and  chances  for 
innovative  starting  companies 
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lavid  Talbot,  European  Commistion 


Prolessiunal  Software  Oevefopment  in  Europe 
•  A  Brief  Assessment 


Professional  Software  Development  in 
Europe 


•  The  “economic  dimensions” 


•  A  (personal)  view  of  strengths  and  weaknesses 


•  EC  support  for  improving  our  capabilities 


The  European  Commission  -  Software  Systems  and  Best  Practice 


The  “Traded”  Market  in  Europe  (1996) 


Professional  Services 
(not  including 
"support"  services) 
37.S  becu 
52% 


Application 
soluliorB  16a  becu 
23% 


AppicaBon  tools 
lOabecu 
15% 


System  SoftMre 
72  becu 
10% 


Source  IDC 


Total  Market  =  72.7  becu 


The  European  Commission  -  Software  Systems  and  Best  Practice 
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rivivsanjcwt  m  ^u«V|>c 

•  A  Brief  Assessment 


The  ^‘Hidden  Market”  in  Europe 


•  Non  IT  (“User”)  Industries  -  producing  60-70V*  of  ill  soflwire 

•  “Enterprise”  systems  -  control  of  costs,  improve  quality  of  service, 
optimise  processes,  reduce  distance  between  customers  and  suppliers 

•  Embedded  systems  -  (aircraft  to  shavers)  -  provide  more  features, 
increase  usability,  differentiate  product  ... 


Increasingly  a  “core  competence”  in  all  developed 
sectors  of  the  economy 


The  European  Comnussion  -  Software  Systems  and  Best  Practice 


Strengths  (+)  and  Weaknesses  (-)  in 
The  “Traded”  Market 


Profnsional  Services  ^jgfclBonaoMlonB 

(not  including  23% «/-  AppUctfonlools 


The  European  Commission  -  Software  Systems  and  Best  Practice 
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‘  A  Brief  Asse^ment 


Software  Capabilities  in  Europe 


Recently  an  analysis  was  made  of  the  productivity  of 
software  professionals  and  the  quality  of  the  resulting  software 
by  country.  Six  of  the  top  ten  most  productive  countries  in  the 
world  are  EU  member  states,  and  six  of  the  top  ten  suppliers  of 
software  with  the  lowest  defect  levels  are  also  EU  member 
states 


Kerry  Hanson,  Director  Tl  ex  White  House  OST 


The  European  Commission  -  Software  Systems  and  Best  Practice 


The  Fourth  Framework  Programme:  “ESPRIT” 
Underpinning  Technologies  and  Long  Term  Research 


Software 

Technologies 

14% 


Multimedia 

Technologies 


8% 


Long-term 

Research 

10% 


The  European  Commission  -  Software  Systems  and  Best  Practice 
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Siemens'  SoHwarc  Initiatives 


The  Fourth  Framework  Programme:  “ESPRIT” 
Focused  Clusters 


f  High  \ 
Performance 
computing  and 
Networking  . 

\  ii%  / 


!  Integration  > 
in 

Manufacturing 

\  12%  J 


Technologies 

for 

Business 

Processes 

^  9%  y 


/  Ojpen- 
I  Mienprpeeasor 
i  S^tems 
\  Initiative  J 

\  9%  y 


The  European  Commission  -  Software  Systems  and  Best  Praaice 


Software  Technologies:  Objectives 

To  ensure  that  European  software  developers  in 
both  vendor  and  user  organisations  continue  to 
have  the  skills  and  tools  necessary  to  build  the 
increasingly  complex  and  varied  systems  demanded 
by  the  market 

Widen  the  spectrum  of  IT  supported  applications 

Make  future  systems  more  attractive  and 
acceptable  to  the  user 


The  European  Commission  -  Software  Systems  and  Best  Practice 
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Siemens'  Software  Initiatives 


OaviU  Talbot,  European  Commission 


Professional  Software  Development  in  Europe 
•  A  Brief  Assessment 


Current  challenges 


Current  technologies 
inadequate  to  deal 
with  new  challenges 

New  R&D 


Current  practice  makes 
inadequate  use  of 
available  technologies 

Best  Practice 
(ESSI) 


Several  constraints  to 
the  deployment  of  leading-edge 
technologies 

Technology  Transfer 


The  European  Conunission  -  Software  Systems  and  Best  Practice 


Technology  Adoption  Cycle 


RTO]  >  Trial  AppUcations 


•  acM  iMl  tor  vaaHNa 


5;^ 

rWrtappHeabmiy  rMt 


time 
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Uav  lU  Utbul,  turupean  LummiMiun 


Proie»btoi)ai  ^oilvvart;  U^vclupm^nt  in  kurupe 
-  A  Brief  Assessment 


Useful  addresses 


•  ESPRIT  Information  Desk 
Tel.  +32  2  2968596 

Fax  +32  2  2968388 

http://www.cordis.lu/esprit/home.html 

•  Info  packages 

http://www.cordis.lu/esprit/src/info97.htm 

•  Software  Technologies 
http://www.cordis.lu/esprit/src/$thome.htm 


The  European  Commission  -  Software  Systems  and  Best  Practice 
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Dialogue  at  SEPG  Conferences 


itj 


1989  - 1996 

1997  - ? 

?-? 

Local 

Community 

Scientific 

learning 

learning 

learning 

Case  studies 

Change  models 

Model  capability 

ROi  reports 

IDEAL 

Empiricai  studies 

2 

3 

4 

TcraQocst 
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Approved  tor  public  retooBet 
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Recent  History  of  Change  Models 


Diffusion  of 
innovation 
(Rogers) 


Total  quality 
management 
(Deming;  Juran; 
Crosby) 


Process 

maturity 

(Humphrey) 


Organization 
development 
(Berkhard; 
Bennis; 
French  &  Bell) 


Corporate  Business 

culture  process 

reengineering 


<S  Kennedy; 
Peters  & 
Waterman) 


(Hammer  & 
Champy) 
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Alternate  Approaches  for  SPI 


Top-down 

VS. 

Bottom-up 

Tochnology  focus 

vs. 

Process  focus 

Organizational  change 

vs. 

Process  change 

Organization  focus 

vs. 

Project  focus 

T 

^^^TemQuest 

4 

MeSMseftPI 
e  IMr  TenQuMt 
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UeyunU  ou«  Mudie> 


Issues  in  Designing  SPI  Programs 

Top-down  vs.  Bottom-up 

who  drives  the  change  process? 

Technology  focus  vs.  Process  focus 

where  is  the  leverage  for  improved  results? 

Organizational  change  vs.  Process  chat 

how  much  supporting  infrastructure  is  needed? 

Organization  focus  vs.  Project  focus 

global  vs.  local  problem  solving? 


^TeraQuest 
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Seven  TQM  Tools 


Powerful  tools  for 

process  change  inconsistent  with  software 


No 

training 

Misunder-_\. 

standings 


-  Wrong  version 


Lack  of 
standards' 


PoorC¥ 


Codbig  Test  case  Design  Pegts. 


Oefsets  reported  by  customers 


Documen- 
'  tation 


Formatting 

errors 


May  have  less 
power  for  some 
organizational 
changes 


kTcniQiicst 


MeSdierwi 

•  fferTwoOuMt 
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echnology  Diffusion 


Cumulative 
rate  of 
adoption 


laggards 


Lata  majority 


Early  majority 

Early  adopters 
Innovators 


Time 


^  Rog«f»,  E.  (1983).  Dlttuslon  of  Innovations  (3rd  ed.).  New  York:  Free  Press. 

K^TeraQuest  ii 


intervention  or  Behavior? 


.Technology 
^  diffusion 


Dom  this  curve  describe  the 
effects  of  personality  types, 
or  the  match  between  the 
project’s  life  cycle  stage  and 
the  technology  being  adopted? 


TcraQncst 


^aumalority 


Early  majorfty 

Early  adopters 
Innovaters 


Maeau  or  aw 
Piet?  TaraQMBit 
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Stages  of  Change  Commitment  || 

1 

Commitment 

Phase 

Acceptance 

Phase 

Preparation 

Phase 

8.  Internalization^^  1 
7.  Institutionalization K 

6.  Adoption tr  i 

e  ■  «  II  At  ^  ftr««liokl 

S.  Installatioi^^  | 

4.  Decision  ^ 

jT  disposition 

3.  Understanding^  ttirwhoid  | 

2.  Awareness^^  j 

1.  Contact  ar 

*1*  Conner,  0.  R.  (1995).  Managing  ar  r/ie  Speed  C/iange.  New  York:  Villard. 

^TeraQuest  u 

Integrating  Change  Models 


Acting 


Are  the  change  commitment 
phases  an  altemative  to  IDEAL,  a 
description  of  change  processes 
within  an  IDEAL  cycle,  or  an 
implementation  of  Technology  '' 
Change  Management  at  level  5? 


^TeniQacst 
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prganizational  Change  -  *Big  3*  Mode^ 


Level  of  change 

Focus  of  change 

Type  of  change 

Macro- 

evolutionary 

Industry 

environment 

Corporate  identity 

Micro¬ 

evolutionary 

Stage  in  organiza¬ 
tion’s  life  cycle 

Organizational 

coordination 

Revolutionary 

Political 

Power  &  control 

Kanter,  Stein.  &  Jick  (1992).  The  ChaUenge  of  Organizationa/  Change.  Hew  York:  Free  Press. 
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Recent  Research  on  Org.  Change 


Scope  of  research: 

*  34  organizations  surveyed  by  U.  of  Michigan 

*  5  in  depth  case  studies 

Organizational  change  driven 

*  change  driven  by  demands  of  business  environment 

*  not  by  intention  to  change  the  internal  organization 

*  literature  emphasizes  internally  driven  change  (little  support) 

Change  leadership: 

*  change  described  as  conversion  of  a  top  leader 

*  however  change  driven  a  change  in  the  leaders 

T.  D«nl«on  (1990).  OrganlztOonal  Cuttun  and  OrgtntiMlontl  Efftctivwss.  N»wYorfc:WHty 

llLTcniQacst  ic 


•  mr  TwaOMM 
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lig  3’  Model  Revisited 


iLevel  of  change  |Focus  of  change  {Type  of  change 


Macro* 

evolutionary 

Micro¬ 

evolutionary 


Industry 

environment 


{Corporate  identity 


Stage  in  organize-  Organizational 
tion’s  life  cycle  coordination 


■Revolutionary  IPolitical 


Power  &  control 


Kanter,  Stein,  &  Jick  (1992).  The  Challenge  of  Organizational  Change.  New  York;  Free  Press 

K.TeraQuest  17  .“-Jrl; 
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C  1997  TeraOuest 


Some  Testable  SPI  Hypotheses 

Software  processes  cannot  be  improved  if  they  are 
constantly  being  sacrificed  to  schedule  pressure 

Process  learning  occurs  faster  when  there  is  a  common 
process  framework  against  which  to  compare  results 

SPI  will  not  be  sustained  if  projects  do  not  experience 
benefits  after  reasonable  time  and  effort 

Sophisticated  processes  or  metfiods  must  be  adopted 
and  mastered  in  stages 

The  full  benefits  of  an  individual  process  cannot  be 
realized  if  it  is  improved  in  isolation 


kTeraQucst 
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•  IWTTwiQwiW 


Wednesday  18  |une 


(C303)  S-9 


Conclusions 


The  SPI  community  needs  to  begin  studying  the 
effectiveness  of  the  models  that  guide  their 
implementation  of  improvement  programs. 

*  what  tools  are  relevant  to  what  approaches? 

*  what  assumptions  underlie  how  the  approach  is  applied? 

*  does  the  modei  describe  the  intervention  or  resuiting  behavior? 

*  what  organizationai  state  is  most  conducive  to  the  approach? 


The  SPI  community  needs  to  : 

*  measure  the  results  of  assumptions  underlying  SPI  programs 

*  characterize  the  capabiiity  of  different  improvement  models 

*  describe  how  they  can  be  integrated  in  SPI  programs 


TeraQuest 
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A  Vision  of  the  Future  at  SEPG? 


1989  •  1996 

1997 -? 

?.? 

Local 

Community 

Scientific 

learning 

learning 

learning 

Case  studies 

Change  models 

Model  capability 

ROI  reports 

IDEAL 

Empirical  studies 

2 

3 

4 

k  TeraQuest 
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Siemens'  Initiatives 


SIEMENS 


ESEPG  ‘97 

European  Software  Engineering  Process  Group  Conference 


Competence  in  Software  and  Engineering 
<  Siemens'  Software  Initiatives 


Soltw^are  &  Engineering 


CL'S  i  e  m  e  n  s 


Siemens'  Software  Initiatives: 

•  Impact  of  Software  S  Engirwering 
on  Siemeiw'  businesses 

•  Goals  and  approaches 

•  Focus  Areas 

•  Standards  of  Excellence  top^* 

•  ConfeieiKe  "Competence  in 
Software  and  Engineering" 

•  Group-specific  Initiatives 

Experience  at  Siemens'  Public 
Communication  Networlcs  Group: 
"Cut  Cyclu  Time  by  50%  by 
Comprehensive  Redesign  of  the 
Endre  Product  Life  Cycle 
Process" 

•  iMugMugeew 

SSmbmaO. 
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Siemens 

System  integrator  with  eight  core  business  areas 


□  We  are  an  electrical  engineering  and  electronics  company 

□  We  are  the  systems  integrator  in  the  global  market 

□  We  stand  for  innovation  and  responsibility 

System  integrator  with  eight  core  business  areas; 

Q  Energy 

Industry  and  trade 
Communications 
Information 


Transportation 
Health  care 
Components 
Lighting 


Software  is  of  strategic  importance 
within  numerous  divisions 


Sf 
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Software  Status  at  Siemens  | 


Software  Development  has  become  a  significant  success 
factor  in  most  of  Siemens'  business  transactions 


60  %  of  Siemens'  sales  are  based  on  products  /  systems 
utilizing  software  developed  in-house 


25,000  Software  designers  are  employed  worldwide 


iIMMhI 


Fundamental  changes  made 
to  improve  both  quality  and  efficiency 
in  software  development 
are  becoming  prime  competition  factors 


Software  is  a  core  competence  for  our  business  | 


Software  competence  has  become 
a  strategic  goal  for  Siemens 


KMSOMSCPOsr 
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The  fvp  -Software  initiative  -  Goals  and  Approaches 


Keep  software  expertise  at  Siemens  among  ttie  best  world-wide 

through: 

O  focussing  and  bundling  the  current  activities  of  the  groups 

O  derive  group-specific  software  initiatives 
that  fbojs  on  business-specific  goals 

O  build  up  and  access  both  internal  and  external  knowledge  bases  (including 
benchmarking  and  the  recognition  and  speedy  adaption  of  'best  practices') 
to  enable  us  to  innovate  faster  and  with  less  risk 

O  continuous  exchange  of  information  and  experiences  regarding  ways  to  increase 
software  expertise,  e  g.  through  inter-group  workshops 

Q  actively  using  an  electronic  forum  on  the  Intranet  to  support  the  exchange  of 
infonnation  in  the  'software  community* 

O  making  the  software  expertise  of  Siemens  more  visible  externally 
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SIEMENS 

Siemens'  Software  Initiative 
Focus  Areas 


O  Project  Management 
and  Organization 

O  Architectures  for  Software  Products 
O  Architecturs  for  Embedded  Software  and  Systems 
O  Processes 

(process  chains,  process  assessments,  process 
improvement,  innovative  processes) 

O  Engineering  for  Industrial  and  Power  Plants 
3  Human  Resources  Management 
3  Software  Marketing  I  Software  Service 
O  top^'”:  the  Siemens'  Standards  of  Excellence 

♦^^1^  mr 
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Successful  Software  Competence  is  influenced  by  many  Factors 
top^'’‘  -  a  "Thermometer"  for  the  Software  Business 


O  Costs  ==>  via  administrative  reporting 


O  Customer  satisfaction 
O  Tlme^o-market 
O  Quality 
O  Productivity 
O  Process  Maturity 
O  Technology  Maturl^ 

O  Human  factors 
O  Communication 
O  ‘Skills' 

O  Infrastructure 


How  healthy  are  we?^ 


□  Improvements  must  be 
measured  and  traced, 

□  for  controlling  purpose, 

□  to  make  visible  successes 
and  benefits. 

□  This  requires 
management  and 
controlling  instruments  at 
both  project  and 
management  level. 
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topS'’^  Charts  •  Example 


Chwtl: 
CiMtemer 
Satisfaetien 
Goa/: ... 


Chart  3: 
Cycle  Time 
Goa/: ... 


Chart 
Process 
Maturity 
Goa/: ... 


Chwt2: 
Quality 
(PraensH 
Proeuci) 
Goa/. ... 


Chart  4: 
Pnxiueilvlly 
Goa/: ... 


ChMtS: 
Technology 
Maturity 
Goa/: ... 
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International  Siemens  Conference  and  Exhibition  I 
Competence  in  Software  and  Engineering  I 


O  Plenary  sessions 
O  Panel  discussions 
0 180  contributions, 
talks,  poster 
sessions,  demos 
O  in  24  pavilions 


O10-11June*97 
O  Munich  Airport 
O  Siemens'  groups  and 
their  operating 
companies,  corporate 
divisions,  Siemens 
Intemationai 
Companies 


0 1000  attendees, 
Siemens'  employees 
and  customers  from 
around  the  world 

To  promote: 

O  exchange  on  info 
and  best  practices 
O  further  improvement 
O  further  innovation 
O  a  motivational  boost 
to  the  initiatives 
O  make  our 
competence  more 
visible  to  our 
customers 

EwsesaetCPO  V 


SsOwsrs IiiUNn/  Cowpetsrtcs m SoOissrs  sndEngwsnng  •  fl»smsn»~  Se4wsrs  inastrvs 


Wadnciday  18  |unc 


(C303)  S-l 


Siemeni'  Software  Initiatives 


SIEMENS 


The  Software  Initiatives  of  the  Groups  and  the 
Siemens  International  Companies 


Transportation 

AT.VT 


Energy 

EV.KWU 


I  Communications 


ON,  PN.  SI 


Siemens  Int  CompA 
PSE, ...  ) 


Healthcare 

Med 


Information 

SNI 


Industiy  . 
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Cut  Cycle  Time  by  50% 
by  Comprehensive  Redesign 
of  the  Entire  Product  Life  Cycle  Process 


The  story  of 

the  creation  of  optimized 
processes  within 

i  Siemens’  Public  Communication 

*  Networks  Group  (OEN) 

and 

their  successful  application  to 
Q  the  switching  system  EWSD 
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Overview 


1.  Basic  Situation  and  Requirements  for  the  Processes 

About  products,  organization  and  telecommunication  markets 


2.  The  Process  Redesign  Project  PEPP 

About  goals,  phases,  time  frame  of  an  ambitious  project 


3.  The  resuits:  New  Core  Processes  and  Optimized 
Process  Steps 

About  Business  Opportunity  Scanning,  Product  Line  Management 
and  Product  Provisioning  Processes  and  "levers" 


4.  Successful  Introduction  of  the  New  Life  Cycle  Process 
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Siemens  Public  Communication  Networks  Group  (OEN) 
is  one  of  the  leading  suppliers  in  telecommunications  ... 


-  aoTaan'**"®" 


Access  Networks  (AN) 

Broadband  Networks  (BN) 

Internet  Solutions  (IS) 

Mobile  Networks  (MN) 
Network-Engineering  (NE) 
Communication  Cable  Networks  (NK) 
Switching  Networks  (SN) 

Telecom  Management  Networks, 
Intelligent  Networks  (Tl) 
Transport  Networks  (TR) 
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The  broad  product  portfolio 
and  the  decentralized  organization 
require: 

□  The  product  life  cycle  process 


^  must  be  generic  in  essential  parts  and  allow  to  create 
variants  for  different  project  classes 

^  must  allow  seamless  continuity  accross  the  business 
units  in  case  of  joint  developments 

^  must  include  clear  strategic  target  setting 


_fip 
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Customer  requirements  for  telecom  equipment 
are  extremely  challenging 

/ 

□  e.g.  customer  requirements  for  swiching  systems 

•  System  availability  >99.99943%  (3  min.  downtime/year) 

•  Permanent  operating  time  10-20  years 

•  System  modification  and  expansion  during  operation 

•  New  versions  fully  downward-compatible 

•  Adaptation  to  operator-specific  standards  (customer  projects) 
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Siemens'  EWSD  is  the  worid's  best  selling  switching  system 


□  Installed  ports  today 

•  710  million  ports  worldwide 

EWSD  market  share;/^J|SO 

•  130  million  ports 

•  92  countries 
.  300  operating  companies 

□  EWSD  success  factors 


□  The  prognosis 


1 .8  billion  ports  worldwide 
in  2010 


•  Annual  release  of  an  extended  SW  version 

•  Hardware  modernization  every  3  years 

•  Use  of  the  most  modem  and  efficient 
microelectronic  components 

•  Setting  of  standards  with  fully  customized 
chipsets  (ISDN) 

•  Highest  reliability 


i»P 
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To  Stay  competitive  and  to  increase  market  share  require: 


□  The  product  life  cycle  process  must  include 


^  search  for  new  business  opportunities 
independent  from  operational  sales  task 

^  customer-oriented  evaluation  of  realization 
alternatives 

^  close  cooperation  with  the  customer 

a  maximum  of  parallelism  of  the  subprocesses 

^  cross-functional  project  control  with  overall 
responsibility 
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The  situation  in  the  telecommunication  market  has 
changed  dramatically  in  the  past  few  years  ... 


•  Traditional  markets  are  saturated 

•  Considerable  price-pressure  in  young  markets 

•  New  operators  and  globalized  activities  of  traditional 

operators  because  of  market  deregulation  A 

•  Globalization  of  competitors  m 

•  Telecommunication  and  information  technology  are 

growing  together  ^ _ _ 

' - ■r— 
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The  dramatic  changes  in  the  telecommunication  market 

requires: 

□  The  product  life  cycle  process 

must  shorten  the  time  to  market 

must  drastically  reduce  the  throughput  times 

1^  must  increase  productivity  to  reduce  investment 
for  new  products 

.  ^  must  target  the  product  life  cycle  to  design  to  cost.^^K 
\  design  to  service  and  design  to  customers  need 
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Overview 


1.  Baeic  Situation  and  Requirements  for  the  Processes 
About  products,  organization  and  talacommunication  marfcats 


2.  The  Process  Redesign  Project  PEPP 

About  goais,  phases,  time  frame  of  an  ambitious  project 


3.  The  results:  New  Core  Processes  and  Optimized 
Process  Steps 

About  Business  Opportunity  Scanning,  Product  Line  Management 
and  Product  Provisioning  Processes  and  "ievers" 


4.  Successful  Introduction  of  the  New  Life  Cycle  Process 


iM^Mesesevr 

esMHMAC  mr 
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PEPP  should  optimize  the  processes  in  order  to  cope  with 
the  of  product,  organization,  and  market  requirements 


□  The  most  important  goals  of  the  PEPP  project: 


More  accurate  product  definition  to  guarantee  market 
success 


Shorter  cycle  times  to  accelerate  innovation 


•  Reduced  cost  and  increased  productivity  to  set  resources 
free  for  new  products 
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The  PEPP  project  has  been  subdivided  into  3  phases 


Phase  1: 

Project  definition 


Phase  2:  \  Phase  3: 

Work  out  improvement^  Realisation 


•  Detection  of  problem 
areas 

•  Definition  of 
'levers'  (areas  of 
improvement) 

e  Installation  of  cross- 
furrctional  teams  and 
of  a  steering 
committee 


•  Detailed  analysis  of  quality,  cost 
and  throughput  time  of  exixting 
process  steps 

•Woitc  out  of  improvement 
measures  in  teams,  resulting  in: 

-  new  processes, 

-  optimized  steps  of  existing 
processes 

•  new  or  improved  methods 

e  Release  of  improvements  by 
steering  commettee 


•  Verification  of 
improvements  in 
pilot  projects 

•Tuning  of  measures 
according  to  the 
experiences 

•  Full  roll-out, 
including  provision 
of  process 
documentation 


SIEMENS 


The  PEPP  project  was  started  12/94, 
the  new  processes  were  introduced  for  EWSD  in  1/96 


1995 

1996  1 

4  I  5  I  6 

7  I  8  I  9 

10  I  11  I  12 

1  1  2  1  3 

-1  1  .5  1  6, 

7  1  8  1  9  1 

Phase  2  (Step  1): 

Work  out  improvements 
(Generic  part) 


Phase  2  (Step  2): 
Business  unit  specific 
adaptions  _ 


Introduction  for  EWSD  product  life  cycle 
Subprocesses:  BOS  /  PLP  ^  PPP 
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Overview 


1.  Basic  Situation  and  Requirements  for  the  Processes 

About  products,  organization  and  teiecommunication  markets 

2.  The  Process  Redesign  Project  PEPP 

About  goals,  phases,  time  frame  of  an  ambitious  project 


3.  The  results:  New  Core  Processes  and  Optimized 
Process  Steps 

About  Business  Opportunity  Scanning,  Product  Line  Management 
and  Product  Provisioning  Processes  and  "levers” 


4.  Successful  Introduction  of  the  New  Life  Cycle  Process 

tiwiiiesaeoiT 
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The  new  product  life  cycle  consists  of 
3  closely  interacting  core  processes 


1 


Product  Line 
Management  Process 
(PLP) 

\ 

Product  Provisioning  Process!  \ 
(PPP)  \  \ 

Development  (PPP;D)  )  \  \ 

\  \ 

Business  \ 

Opportunity  \ 

Scanning  Process  ) 
(BOS)  / 

Market  Introduction  (PPP:M)  )  /  j 

/  / 

Production  Introduction  (PPP;P)  )  /  / 

. .  /  / 

;  OEM  Integration  (PPP:0)  /  / 

- ^ _ _ 1  / 
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The  BOS  process  involves  continuously  and  proactively 
searching  for  new  business  opportunities 


The  4  phases  of  the  Business  Opportunity  Scanning  Process 
(BOS): 


1  \ 

2  \ 

3  \ 

Recognize 

\  Formulate  \ 

Conduct  \ 

business 

/  business  / 

feasibility  / 

opportunities  ^ 

opportunities  / 

studies  / 

SIEMENS 


1 


in  the  PLP  process  an  entrepreneurial  product  line 
strategy  is  formulated  and  implemented 


The  phases  and  process  steps  of  the 
Product  Line  Management  Process  (PLP): 


1 

Plan  \  Evaluate  \  Select  a  \ 

\  \ .  \  Version 

product  ^business  )  feasibility  ) 

/  /  /  packaging/ 

line  /  opportuni-/  alternative  / 

strategy/  ties  /  / 
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The  BOS  and  PLP  processes  run  in  parallel 
and  are  closely  linked 


BOS  process 

1  Racognizt  \  Formulate  \ 

Conduct 

\  Draw  up  a  \ 

businaas  )  buainaaa  \ 

faaaiblUty 

\  bualnata  \ 

opportunttlaa  /  opportunKlaa  / 

1 - -  -  -• 

atudiaa 

- 7 

/  ^  ^  / 

Perform  controlling 


Baseline  decisions  made  by; 
- - '  •  Process  owners  of  ROS  P 


Process  owners  of  BOS,  PLP  and  PPP 
Managers  of  development  departments  involved 


SIEMENS 

The  development  process  is  optimized  by  different  "levers" 
each  of  them  having  effect  on  one  or  more  phases 

The  phase  model  of  the  development  process  (PPP:D); 

Analysis  \  Design  \  lmplemen-\  lntegration\  System  \ 
_ _ /  tation  /  test  /  test  / 

Examples  for  levers  and  the  phases  they  influence: 

EWSO  2-cycle  model 


Fast  analysis  Reduction  of 

process  design  spec. 


Reduction  of 
test  spec. 


Early  detection  and  correction  of  errors 


Efficient  testing  by  test  teams 
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The  lever  "fast  analysis  process"  accelerates 
the  analysis  phase  by  50% 

Basic  principles  /  goals:  ' 

*  Redesign  and  acceleration  of  analysis  phase 

•  Link  between  BOS  /  PLP  processes  and  the  development 
process 

"^Process  modifications;  ^ 

‘Direct  information  passing  by  business  opportunity  handover 
workshops 

‘Reduction  of  documentation  volume  (Delta  feature  specs, 
instead  of  complete  system  functional  specs.) 

‘Non-urgent  activities  in  later  phases  (e.g.  updating  of  system 
specs.) 
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The  lever  "efficient  testing  by  test  teams”  reduces 
throughput  time  and  costs  for  the  test  phases 

^Basic  principles  /  goals 

‘Redesign  and  more  efficient  processing  of  the  test  phases 
‘  Formation  of  feature-group-oriented  test  teams  out  of 
development  and  system  test  staff 

‘  Reduction  of  testing  volume  by  elimination  of  redundancies 
‘Cost  saving  by  reduction  of  test  beds 

^Process  modification: 

‘"Clearing  out"  of  milestones  in  test  phases 

‘More  parallelism  between  integration  test  and  system  test 

‘  Use  of  testing  teams  for  common  test  steps  of  test  phases 
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Synchronization  points  allow  seamless  continuity  across 
the  business  units  in  case  of  joint  development 


PLP 

PPP  \  P*-*’  \ 

Develooment  IPPPtD)  )  \  \ 

1  BOS  ^ 

1  Market  Introduction  (PPP:M)  )/  / 

1  Production  Introduction  (PPP:P1 )/  / 

'■  OEM  Inteqration  (PPP:01  }  f  / 

O  ^  ^  ^  ^  O 


B10  B50  B100  B130  B200  B410  B550  B600  B700  B800  B900 


Qusiness  FeasibilH;  Start  of  Definition  Artalysis  Bring-up  Beta  Customer/ Transfer  End  End  of 

Opportunity  Study  &  Product/  of  compete  complete  Release  Maricet  to  of  Contractual 

Proposal  Business  Version  Require-  (opt)  Release  Product  Martte- Obligations 

Plan  ments  Support  ting 
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itciiicio 


Overview 


1.  Basic  Situation  and  Requirements  for  the  Processes 

About  products,  organization  and  telecommunication  markets 

2.  The  Process  Redesign  Project  PEPP 

About  goals,  phases,  time  frame  of  an  ambitious  project 

3.  The  results:  New  Core  Processes  and  Optimized 
Process  Steps 

About  Business  Opportunity  Scanning,  Product  Line  Management 
and  Product  Provisioning  Processes  and  "levers” 

4.  Successful  Introduction  of  the  New  Life  Cycle  Process 
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SIEMENS 

The  new  product  life  cycle  process 
has  been  successfully  introduced 

^  More  accurate  product  definitii^  Shorter  cycie  times 

Exceptions  at  system  release  New  products/Vereions 

CIH - I  H — ( 


Modified  features  per  version 


Customer  projects 


Redesign  probability  for  ASICs 


f«NeMMS90V 
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Customer  projects 
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SIEMENS 


For  EWSO  customer  projects  throughput  times 
have  been  cut  by  an  average  of  48% 


Before  optimization: 
average  of  11.3  months 


After  optimization: 
average  of  5.9  months 


•ftp 
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Throuput  times 
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SIEMENS 


The  new  product  life  cycle  processes  have  been  accepted 
immediately  by  94%  of  the  staff 


□  Success  factors  of  the  process  redesign  project: 


•  Many  of  the  people  who  now  have  to  live  with  the  new  processes 
were  involved  in  the  cross-functional  project  teams 

•  High  identification  with  the  project  goals  caused  by  intensive 
communication  and  careful  explanation 

•  Good  support  by  the  management 

•  Up-to-date  electronic  documentation  system  with  hyperlinks 

•  Training  courses  held  by  people  involved  in  the  project 

•  Clear  responsibility  for  the  new  core  processes  (process  owners) 

•  Continuous  improvement  process  integrated,^ _ — Zxina^**-  — 
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Siemens'  Software  Initiatives 


SIEMENS 


The  Industry  Creates  Challenges  to  Software  and 
Systems  Engineering  and  Engineering  of  Industrial  Plants 


top  Quality 


Just  in  Time 


Software  Initiative 


at  reasonable  cost 


rwr 

I*  fleBcturM 

t  •  organization 
'  by  developing  sound: 

•  akiiis 

•  innovations 

•  sociai  anvironmant 

•  ate. 
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MANAGING  CULTURE 
CHANGE 

Who  makes  the  change  work? 


outside  looking  in 


MANAGING  CULTURE 
CHANGE 

The  Approach 

Boring  -  We’re  drawing up  a  process  map 
of  the  orgaiiisatioh 
ZZZZZZZZZZZ 

Interesting  -  We’re  finding  out  how  things 
wohc  rouiid#^^^^^  - 

outside  looking  in 
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MANAGING  CULTURE 
CHANGE 

The  Approach 

Boring  -  We’re  embarking  on  a  programme 
of  continuous  improvement 
YAWN 

Interesting  -  We’re  going  to  make  a  few  things 
better  round  here 
ZAP 

outside  looking  in 


MANAGING  CULTURE 
CHANGE 

The  Approach 

Boring  -  The  Executive  Committee  are  having  a 

3  day  workshop  to  develop  the  programme 
Here  we  go  again 

Interesting  -  You’re  going  to  have  to  tell  us  the  best 
things  to  attack 
Do  they  mean  us? 

outside  looking  in 
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MANAGING  CULTURE 
CHANGE 


Evolved  with  the  CustonCT^^^^^ 
The  right  name 

Change  programmes  cha^^^^^^mp 
Change  is  continuous  X^^PUP 


outside  looking  in 


MANAGING  CULTURE 
CHANGE 


Better  business  solutions 
Service  excellence 
Responsiveness 
Personal  leadership 
Performance  management 


outsiae  looKing  in 
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MANAGING  CULTURE 
CHANGE 


Better  business  solutions  means  - 


Change  the  culture 
Understand  the  customer 
Understand  their  business 
Customer  obsessed  behaviours 


outside  looking  in 


MANAGING  CULTURE 
CHANGE 

Service  excellence  means  - 


Listen  to  customer  concerns 
Do  something  about  it 
Get  customer  approval 


Stick  to  the  priorities 


outside  looking  in 
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MANAGING  CULTURE 
CHANGE 


Responsiveness  means  - 


Skills  groups 

Assignment  based  working! 
Flexible  organisation 


outside  looking  in 


MANAGING  CULTURE 
CHANGE 

Personal  leadership  means  - 

We’re  all  being  watched 
Define  good  behaviours 
Reward  the  good  ones  correct  the  bad 


Get  feedback  ,  ,  , 

outside  looking  m 
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MANAGING  CULTURE 
CHANGE 

Performance  management  means  > 


Proper  measurement 
Proper  feedback 
Proper  coaching 
Done  by  the  capable 


A  continuous  process 

outside  looking  in 


MANAGING  CULTURE 
CHANGE 


SUMMARY 

Change  is  continuous 
Customer  expectations  grow 
Old  behaviours  need  examination 
People  need  help  to  respond 


outside  looking  in 
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MANAGING  CULTURE 
CHANGE 


We  all  kQOW  ilialiwe  the  culture 


The  secret  is^o  do  t&e^  organisation 

not  to  the  organisation 
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Software  Measurement 
Across  a  Global  Enterprise 

Interim  Report 


ESEPG  97 
June  16-19, 1997 
Gerald  Pasternack,  Citicorp 
Dave  Zubrow,  SEI 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 


Overview _ Q 

Background  information 

•  why  enterprise-wide  measures 

•  infrastructure 

Enterprise  measures  selected 
Challenges,  obstacles,  &  solutions 
Status 

•  pilot  implementation 

•  next  steps 
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Objective 


o 


To  establish  an  enterprise  metrics  program 
which  characterizes  software  progress  and 
performance  across  a  global  enterprise 

To  establish  initial,  simple  set  of  metrics  that 
can  be  used  across  the  enterprise  to  serve  as 
the  common  "meter  stick”. 

To  deploy  this  so  that  all  organizations  (at  CMM 
Level  3  and  higher)  can  utilize  this  program  as 
part  of  their  ongoing  improvement  efforts 
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Citicorp  Overview 


A  full  service  global  bank  ~>  85,000  staff,  with 
more  than  3,500  locations  in  96  countries 

Strong  technology  thrust 

•  6,000  developers  across  the  world 

•  wide  range  of  development  projects 

Strong  commitment  to  elevating  the  level  of 
software  maturity.  Using  CMM  as  roadmap. 
More  than  50  Assessments  to  date: 

•  63%  at  L1;  17.4%  at  L2;  15.2%  at  L3:  4.4%  at  L4 

•  challenge  is  for  all  Organizations  to  be  at  L3  (or 
higher) 
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Enterprise 


Citicorp  as  a  Global  Enterprise  o 


Multiple  Business  Units  each 
drive  devel^ment  via 
associated  Technology  Units 
(TU) 

Each  TU  may  have  several  ^ 
multi-national  teams  (Work 
Groups) 


ENTERPRISE 


CTO 


1  Bu*in*uUnn|  1  BinlntMlMtl  1  BiniiwMUnn 

1 

1 

1 

(Tachnology  Ufll4^ 

|T«chnalogy  Uni(^ 

jTKhflology  Unifi 

Senior  Technology  Officer 
(STO)  provides  technical 
oversight  via  Citicorp 
Technology  Office  (CTO) 


— 

—  Woik  Group 

— 

1— 

—  Woifc  Group 

L- 

—  WorkGroup| 

$ 
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Why  Enterprise-Wide  Measures  o 

Ability  to  answer  questions  about  the 
enterprise 

•  are  we  getting  better  or  getting  worse 

» is  an  enterprise-wide  improvement  program 
having  an  effect 

Powerful  ability  to  evaluate  new  technologies, 
methods,  and  practices  by: 

•  collecting  identical  measures  to  enable 
meaningful  comparisons  and  trend  analysis 

•  creating  a  large  pool  of  project  data  from  which 
similar  projects  can  be  chosen  for  comparison 
purposes 

Establish  a  visible  ongoing  enterprise  focus  for 
software  engineering  excmience 
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Benefits  To  The  Enterprise  -1  o 


Establishes  a  “baseline”  from  which  to 
measure 

Provides  a  basis  for  inter-orpanizational 
comparisons 

Identification  of  “best  practices”  and  a  starting 
point  for  enterprise  communication  and 
contacts 

Organizational  alignment  around  common 
measurement  processes  and  objectives 

Begins  to  build  an  enterprise  metrics  database 
for  oenchmarking  comparisons 
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Benefits  To  The  Enterprise  -2 


Measure  progress  towards  Corporate 
improvement  goals 

•  increase  Productivity  by  a  factor  of  2  over  5 
years 

•  improve  Quality  by  a  factor  of  10  over  7  years 

•  improve  Predictability  to  within  5%  over  7  years 

•  reduce  Development  time  by  40%  over  7  years 

•  reduce  Maintenance  effort  by  40%  over  7  years 
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Benefits  to  the  Technology  Units  o 


Augments  measurement  work  already  in 
progress  within  individual  organizations 

Provides  closer  alignment  to  business  goals 

Able  to  more  easily  track  progress,  priorities, 
and  trade-offs  in  a  systematic  manner 

Serves  as  a  datum  point  for  technology 
upgrade 

Shares  the  workload  in  developing  detailed 
measurement  standards 
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Business  Strategy  Mapped  to  Metrics 


Example  Indices  for  Business  Goals 


Traceability  table 


BusineM 
Goafs 


PreduO  Supenorty 
I  tmrpw  C«si  Manae«nwnl 
I  I  Custpmef  Focusae  Culute 

mixn 


ScMduO  pndidaMly 

Ip 

• 

E«ton  pfveiciaMty 

• 

Oavetopnwm  ttnw 

A 

A 

i 

OvdMy 

P 

B 

Profteimlx 

• 

Produckwtr 

B 

1 

Mtmlananc*  «fton 

• 

Customar  sMstMfeoe 

m 

1 

1 

_ 
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Infrastructure 
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Established  a  Software  Metrics  Council  (SMC) 

•  Steering  Committee 

•  Working  Group 


Software  Metric  Council 


1 


Chartered  for  the  benefit  of  Tec'  nolo^y  Units 
across  Citibank  to  provide  an  •  cerprise  focus 
on  fundamental  software  metrics 

SMC  Membership  invited  from  Citibank's 
highest  maturity  Organizations  (Level  2+,  3,  and 
higher) 

•  each  Unit  participates  both  as  a  member  of 
Steering  Committee  and  Work  Group 

•  augmented  by  CTO  and  SEI  consultants 

SMC  builds  upon  CMM,  as  well  as  the  work  of 
the  individual  Units.  Extends  this  to  establish  a 
corporate  metrics  baseline 
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Enterprise  Profile 
Initial  Core  Measures 


Schedule  predictability.  Indicator  designed  to 
answer  questions  about  the  enterprise(s)  ability  to 
plan  well  and  deliver  the  products  on  schedule 

Effort  predictability.  Indicator  designed  to  improve 
cost  estimation  and  the  ability  to  bring  projects  in  on 
budget. 

Cycle  time.  Indicator  used  to  track  improvements  in 
getting  products  to  market  as  quickly  as  possible. 

Quality.  Indicator  for  the  quality  of  the  development 
and  testing  process  as  well  as  the  quality  of  the 
software  in  the  field. 

Maintenance  Effort  Indicator  used  to  track  non 
discretionary  maintenance,  enhancements,  and 
defect  corrections  as  well  as  the  number  of  open 
trouble  reports. 

17 
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Enterprise  Profile  -  2 


Customer  satisfaction.  An  indicator  to  track  two 
components  of  customer  satisfaction  -  satisfaction 
with  the  implemented  solution  and  the  working 
relationship  with  the  implementing  team 

Cost  of  Quali^.  An  indicator  that  breaks 
overall  costs  (effort  hours)  into; 

•  rework  -  effort  for  fixing  defects  discovered  prior 
to  release 

•  appraisal  -  effort  for  inspection  and  testing 

•  prevention  -  effort  incurred  by  process 
improvements  aimed  at  preventing  defects 

•  performance  -  effort  associated  with  building  the 
product 
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Challenges,  Obstacles.  &  Solutions 


Precise  definitions 
Culture  differences 
Trying  for  the  100%  solution 
Keeping  senior  management  involved 
Working  open  issues 


21 


Precise  Definitions 


Problem 

•  different  business  concerns,  processes,  native 
languages,  cultures 

•  what  is  a  project 


Approach/Solution 

•  heavy  reliance  on 

-  checklists 

-  templates 

-  graphics 

-  handbook 

-  education  ->  metrics  course 
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Precise  Definitions  -  2 

Key  dates  -  start  and  end  times 

Project  Phases 


AIMmMhia  Funettoiul 
Study  Analyai*  SpacMIcalian 


Project 
Start  Date 


_ 


Estimation 
Start  Date 


Effort  & 
Schedule ' 
Estimate 


End  Date  (ship  date) 


Staff-Hour  Definition  Checklist 


nr-«3aaaaaiiii 

_ l■a!l^^«a^i^rl  I’len ireiaiiietpmiii'FtSficsKa3eBear~iiD.~zl 

Ifcm-  <HWi]'iiaiieiew.wa^.Tigyer»i8B;i;»tst'y;.^  s  I 


OcMtoermrit 

Prinary  etvdtopnMfil  actMly 
Oevetofmtfll  support  acMbts 
Concapi  eowwprolotypoi 

Toots  dotetoprwrff,  ocQucseon,  friitilsfrn  S  support 
Noodollyoted  soPw w  4  tost  Onuors 
MwNtftortco 

Nort-<ieer«tJonary 

Ootoct  conodiort  (tug  tbos) 
oe*or  _ 

Woeuisloryoortrptioffco 
Rototso  upprsdo 
inisrtKO  (•atcmsl  unit  vKoma^ 
EttnoAcemints 

Cop^Sysioms 


Emptoymont  Cliss 
Cecorp  omptoyoo 
FgPtrtt 
Port  Htnt 

Ttnryorot  y  onylpy— 

Subeontrodors 

ConsuNants 
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Handbook 


Software  Metric 
I  Council  Working  I 
Group 

Initial  Core 
Metrics 


Handbook  Contents 

•  Citicorp  Enterprise  Metrics 

•  Indicator  templates 

•  Definitions 

•  Definition  checklists 

•  Pilot  Deployment  Indicator 
Assignments 

•  Pilot  Deployment  Expected  Output 

•  Charter 
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Metrics  Course  (First  Draft) 


o 


Purpose: 

•  ensure  common  understanding,  implementation, 
and  interpretation  of  the  metrics  across  the 
Organization 

•  broadcast  feedback  &  lessons  learned  from  pilot 
implementation 


Components 

•  description  of  template  for  each  indicator 

•  definitions  &  checklist 

•  outline  of  Data  Analysis  module 

-  evaluating  technology  and  process  changes 

-  using  the  indicators  to  guide  actions 

-  analyzing  trends 
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Culture  Differences 


Problem 

•  what  is  accepted  in  one  culture,  may  not  be 
accepted  in  another  (e  g.  measurement  of  effort) 

•  acceptance  of  measurement 

•  English  not  native  language  for  all 


Approach/Solution 

•  education/training 

•  frequent  meetings 

•  expanded  scope  of  involvement 
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Trying  for  100%  Solution  Q 

Problem 

•  so  much  diversity,  can  not  capture  everything 

•  if  waiting  for  100%  solution,  may  never  get  there 

Approach/Solution 

•  concentrate  on  80%  solution 

•  find  out  how  common  everything  is  (languages, 
etc.) 

•  expect  several  iterations 

•  start  with  easy  metrics 

•  expand  to  meet  business  needs 
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Example;  Selection  of  Unit  of  Size 


PRO  SLOC  CON 

-  Relatively  inexpensive  to  -  Many  different  languages 

count  -  4GL,  visual  actions,  code 

-  Tools  fairly  easy  to  write  generators,  etc. 


PRO  Function  Point  CON 

-  language-independent  -  Higher  training  cost 

-  comparability  issues  minimized  -  Possible  higher  counting 

costs 


PRO  Local  Choice  con 

•  Measure  will  fit  local  environment  •  Comparability  is  major 
-  generally  low  cost  initial  headache 

implementation  -  Little  opportunity  for  sharing 

31 


Keeping  Senior  Management  Involved  O 


Problem 

•  oversight  by  senior  management  is  difficult 

•  meetings  involve  heavy  time  commitments  (long 
travel  times) 

•  how  to  obtain  &  retain  support  of  the  metrics 
program  through  all  levels  of  the  organizations 


Approach/Solution 

•  Steering  Committee  met  in  conjunction  with 
other  business  meetings 

•  periodic  status  reports 

•  select  metrics  that  serve  several  levels  of  the 
business  to  ensure  maximum  support 

•  must  gain  support  of  business  sector 

32 
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Working  Open  Issues 

Problem 

•  no  common  reporting  structure 

•  no  mechanism  in  place  to  track,  work,  or 
coordinate  solutions 

•  timely  communication 

-  different  time  zones 

-  no  common  “connectivity”  for  Working  Group 
members 

Approach/Solution 

•  the  CTO  office  and  SEI  consultants  played  this 
coordination  role 

•  frequent  communication  via  FAX,  Federal 
Express,  Email,  conference  calls,  internet 


o 


.  c*in*»*  M*ton  untvv»<y  ^ 

Software  En9inMiing  Inatitutt  w  w  •  •  w  a 


Background  information 

•  why  enterprise-wide  measures 

•  infrastructure 

Enterprise  measures  selected 
Challenges,  obstacles,  &  solutions 
Status 

•  pilot  implementation 

•  next  steps 


o 
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General  Timeline 


1995 


1996 


1997 


iDtc  jjan  : 


iAK- 


:Oc«  ; 


:D«c  -Jm  ; 


WG  Meeting  4 


Santa  Monica  London 


Stei 

Comrii.^v 

Meeting 


♦ 

NY 


♦ 

NY 


♦ 

SEI 


♦ 

Hor  9  Kong 


Handbook 


Pilot 

Implementation 


Pilot  Implementation)-*- 


i  / 


•  Procedures 

•  Develop  automation  support 

•  Refinement  to  indicators 
&  definitions 
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Pilot  Deployment  Goals 


Use  and  refine  the  set  of  measurement 
templates 

Standardize  detailed  definitions  across 
organizations  and  templates 

Solicit  feedback  on  operational  characteristics 
and  implementation  issues  (e.g.,  effort,  cost) 

Gain  a  better  understanding  of  effectiveness 
and  interaction  of  the  proposed  measures 

Develop  supporting  automation 

Consolidate  working  documents,  processes, 
and  tool  kit  to  be  used  for  training  and  future 
implementations 
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Develop  Operational  Aspects  o 

Procedures  for  data  collection  and  recording 
Forms  for  collecting  and  recording  data 
How  data  will  be  stored  and  accessed 
Who  will  collect,  store,  and  access  data 
Tools  to  aid  in  collection  and  analysis 
Roll  up  procedures 
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Automation  Support 


Features  of  support  program 

•  visual  display  of  all  the  indicators 

•  description  and  algorithm  used  for  the  display 

•  number  of  projects  include  in  each  data  point 

•  interpretation  guidelines 

•  definitions 

•  display  of  data  used  in  indicator 

•  side  by  side  comparison  charts 

•  own  contributions  vs  enterprise 


Program  developed  by  GCB-lr>dia 
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Example  Output 


ScfMdufe  PredktiblWy 

Tlw  OeiKtr>w  •  le  understand  the  efieGlivenew  of  our  aSMy  to  esirnale  schedule 
Here  the  mput  are  the  scheduled  dau  rhten  ihe  user  accepkWice  test  (UAT)  was  lo 
tie  concHfed  and  fte  actual  dMe  when  die  UAT  was  completed  along  weh  the  sun 
date  of  codesg  el  Iho  projocl 

The  Fereenfage  Dtviolion  n  tchedule  for  diHerent  calogooes  s  coiculefed  as 
folows 

AbsoMe  value  (Actual  Slap  dafe  -  Ptanned  Siwp  dale) 

Percem Oevi«nn>  — - — - -  -■  '  — '  - *  tOg 

Ptanned  Shp  date  -  Sled  dale  of  codmg 

A  downward  trend  predUs  wryrwmmeni  n  ihe  prediciaMty  and  an  upward  trend 
showsadacineeipradKtaMiy  CIT  wd  ba  Ma  to  enprove  as  away  to  proM 
scheduwe  for  comptewn  of  proiacts  if  we  montor  ms  metre  over  a  period  of  lene 


Maetfi  Larfe  Mediuoi  .Small 


L _ M  S 


-v  MS 

a2i*rs 

lul-'Mi 

t.U  ^T'-. 

1 ■». ‘■.7S 

4S  ins 

241  >V«. 

12S7im 

14  ins 

‘VS  ff*. 

14V  im% 

uirrs 

I|T2»*. 

’2S.t»r% 

ifiins 

N>n  <«■ 

n  IIS 

(s»>rs 

III  i«^. 

llo.  ■«< 

ll<X'W. 

Iwt-VT 

Mw-<I7 

ABf-V? 

Mn-»7 

Data  for  llluatrative  purpose  only 
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Pilot  Implementation  | 

Attributes 

*  Dates,  planned  &  Actual 

•  Effort,  code->  testing 

Group  1 

•  Schedule  Predictability 

•  Effort  Predictability 

•  Cycle  Time 

•  Defects,  DAT  &  field 

•  Effort,  development 

Group  2 

•  Quality 

•  Cost  of  Quality 

•  Effort,  Maintenance 

Group  3 

•  Maintenance  Effort 

•  Survey  Data 

Group  4 

•  Customer  Satisfaction 

41 

Next  Steps 

o 

Report  to  Steering  Committee 

•  definitions  &  templates 

•  lessons  learned 

•  training  &  deployment  plans 

Establish  governance,  centralized 
administration  of  the  program,  forum  for 
sharing  the  information 

Deploy  enterprise  wide 

42 
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Ethics  and  the 
Software  Process 


Revd.  Michael  Cavanagh 

Balmoral  Consulting  Ltd 
Manchester 
+44-161-304-9997 


commonsense(w, balm. demon,  co.  uk 


C  *99/ 


Balmoral 

ConsultiiiK 
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Asimov’s  three  laws  of  robotics 

1.  A  robot  may  not  injure  a  human 

_  being  or  through  inaction  allow  a 

human  being  to  come  to  harm 

2.  A  robot  must  obey  orders  from  a 
human  being  provided  those  orders 
do  not  conflict  with  the  first  law 

3.  A  robot  must  protect  itself 
provided  this  does  not  conflict  with 
either  of  the  first  two  laws 
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Ethics  is 


Doing  good 

Being  honest,  trustworthy  and  loyal 
Not  screwing  people 
Only  screwing  the  competition 
Letting  the  competition  screw  you 
Doing  the  right  thing 
Doing  things  right 


•  McnMi  <48? 
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Consulting 
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Project  Success(1) 


Doing  things  right 


YES  NO 


Doing 

YES 

RR 

RW 

the 

right 

thing 

NO 

WR 

WW 
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Balmdral  , 
Consulting 
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Project  Success(2) 

Compliance  with  procedures 

YES  NO 


YES 

Fitness 

for 

purpose 

NO 


Balmoral 

Cor>sulting 


RR 

RW 

WR 

WW 

Process  and  Product 
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Light  the  blue  touchpaper  and 
stand  well  clear... 


C  MKr<4«iC«van«^  1997  II 


Balmoral 

Consulting 


M. 


m 


The  dilemma 

The  release  of  atom  power  has 
changed  everything  except  our  way 
of  thinking.... 

If  only  I  had  known  to  what  my 
research  would  lead  I  would  have 
become  a  watchmaker 

Albert  Einstein 


O  McumI  Cavan*^  1997  12 


Balinoral  V 
Consulting 
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Operational  States 

•  Use 

•  Abuse 

•  Failure 

CMicn««Cavwv*gM99'  n 

Balmoral 

Consulting 

'im 


1 


w:- 


f 


Problems  of  use 

CFCs  Tobacco 

Credit  reporting  Lotus  ‘Households’ 

Social  change 

Problems  of  abuse 


Diamorphine 
Internet 
‘Chipping’ 
System  intrusion 

t99f  14 


Nuclear  fission 

SABRE 

‘Tagging’ 


Balnioral 

Consulting 
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Failure  to  understand  the  problem  1 

latrogenics 

Year  2000 

Failure  of  the  Software 

AT  &  T  /  DSC  Switch 

Failure  of  the  System 

London  Ambulance 

Intel’s  ’Chipwreck’ 

USS  Vincennes 

Balmoral 

Consulting 

Conflicts 


Omission  and  commission. 


We  have  left  undone  those 
things  which  we  ought  to  have 
done,  and  we  have  done  those 
things  which  we  ought  not  to 
have  done,  and  there  is  no 
health  in  us... 


WedneMUy  18  tune 
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A  Key  Process  Area 

-  Ethics  Management 

To  establish  a  process  whereby  the 
probability  and  severity  of  effects  of  use, 
abuse  and  system  failure  of  the  software 
under  development  are  assessed  from  the 
viewpoint  of  every  stakeholder  and  that 
outstanding  risks  are  managed 
appropriately 


Balmoral 

ConsultinR 
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System  proving 


Proving  that  the  system  will 
behave  in  the  intended  way 
does  not  mean  that  it  will  do 
what  you  Intended  it  to  do. 


•  U«hMlCMn«^  1007  22 


BlifeniSTals 
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Risk 

How  much  risk  do  you  like  I 

taking? 

•  McfiM  tW7  23 

Balmoral 

Consulting 

1 


v< 


Attitudes  to  disaster 


From  the  dawn  of  time 
until  a  few  years  ago  - 

**ActofGod*^ 


From  a  few  years  ago  to 
the  foreseeable  future  - 

“Who  can  I  sue?” 


Cb^ulSrig  ■ 
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Consumer  Protection 
Act  1987 

Unnecessary  to  show  negligence 
Only  requirements  are: 
the  product  was  defective 
the  defect  caused  the  damage 

...  Hability  is ..  imposed  on  the  producer 
of  the  product  (DTI  guide  to  the  act) 


•  ShcMti  C«vjA«^  1997 


Balmoral 

Consulting 
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Negligence  (1) 

In  defence,  the  burden  is  on  the  I 

manufacturer  or  designer  to  show  I 

that  they  took  reasonable  care.  I 

...  ‘best  efforts’.... 

1 

....  the  ‘state  of  the  art’  defence’ ...  I 

(Standards  &  practices) 

•  McnMiCuwanatr*  19»T  jb 

Bak^ial  /  . 
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Negligence  (2) 

“A  design  which  departs 

substantially  from  relevant  1 

engineering  codes  is  prima  1 

facie  a  faulty  design....” 

•  1M;  2t 

Balmoral 

>  ;r  GonsuHinR 

Some  other  concerns 


1 


CIA  (Confidentiality,  Integrity 
&  Availability) 

Ownership 

Power  and  Monopoly 

Professional  ethics  /  Codes  of 
Conduct 
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Professional  ethics 

First,  do  no  harm 
Be  competent 
Uphold  the  law 
Be  honest 

...  and  contribute ... 


Balmoral 

/Consult 
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Agenda _ 

■  ABB  -  the  company 

■  History  of  SPI  initiatives  within  ABB 

■  CMM  assessments  the  ABB  way 

■  TOPP  -  the  Swedish  SPI  initiative 

■  SWITCH  -  the  Swiss  SPI  initiative 

■  TOPP  -  SWITCH  similarities  and  diffences 

■  Lessons  learnt 


I 


Winifred  Menezes 


ABB  Corporate  Research 


unii 


ABB:  A  Short  Summary _ 

■  Employees;  215  000  in  more  than  100  countries 

■  Revenues.  34  MUSD 

■  Example  Products  ^ 

-  Power  Generation:  Power  Plants 

-  Power  Transmission  and  Distribution:  High-Voltage  Substations 


-  Industrial  and  Building  Systems  Drives.  Process  Automation  Systems 


-  ADtranz  (50:50  joint  venture  with  Daimler-Benz):  High-Speed  Trains 


ABB  Corporate  Research 


ABB 
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Software  developed  and  used  by  ABB  | 

1 

software  deliverwN. 

^--Engineering  & 

/  to  customers  \ 

production  support  N. 

/  /''basic/platfornts 

1  \>oftware  ^ 

V^mputationaPi^  _  \ 

V  ^^ntific  softwrarp-'  /EftwaieE  \ 

1  /branch  specify 

rp  ^ois 

\  V^ftware 

/  y  _ / 

\ 

/  \  /data  &  information's  / 

\  xmanaoement  software 

^/productionE^ 

\,  /'ciMtomer  specific  / 

^x:;SQftware 

^ - ^  support  g 

/Corter-en^  (;^^yroll  systemlA  | 

(^^^^ncial  syste^  J 

ABB  Corporate  Research 

c^oS£Pa«7-0«-1«r7 

-^.^MlS-type  sof^afe""^^ 

- #%IPW 

CMM  Assessments  at  ABB 


■  History 

-  Started  in  1993  by  Corporate  Research  Germany  together  with  Power  Plant 
Control 

-  Questionnaire/process  refined  in  cooperation  between  research  centers 

-  Questionnaires  for  levels  2,  3  and  4  exist 

-  Since  then  more  than  30  assessments  performed 


Process 

-  1-hour  introduction  for  all  SW  developers  of  an  organisation 

-  half-day  interviews  with  2-3  senior  members  of  _ 

development  groups/projects 

-  half-day  interview  with  manager 

-  2  weeks  to  summarize  results  and  recommend 

improvement  activities  I  <-evci  i  -  «wn*i. 


L£VELK  OPTMIZINOl 


LeVEL4MANAO£D 


tEVEU.tvtfWlUG£P 


LEVEL  >  •  REPEATABLE 


1-hour  summary  presentation  plus  kick-off  for  SPI  work 


ABB  Corporate  Research 
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From  CMM  to  SPI _ 

■  After  a  CMM  assessment ... 

-  Initiation  of  SPI  activities 

-  Software  development  managers  supportive 

■  When  customer  projects  run  late  ... 

-  Senior  management  gives  SPI  lower  pnohty 

-  SPI  activities  are  "postponed"  (often  means  abandoned) 

■  What  is  needed  ... 

-  Convince  management  top-down 

-  Initiate  activities  with  the  right  incentives  and  resources 


* 


The  Need  for  Top-Down  SPI 


less  than  successful 
software  projects 


successful 
software  projects 


suboptimal 

development 

processes 


inefficient  money 
spending  In  software 
(rework) 


Top-Down  SPI 


strategic  use 
of  software  (reuse) 


ABB  Corporate  Research 


Wednesday  18  |une 


(C306a)  S-5 


T50  Och  Programvaru-Processen  | 

50  %  yearly  improvement 

• 

iyi?rr 

^  Quality 
•  in  process 
-  post  delivery 

\ 

Timeliness 

• 

Each  company  identifies 
own  specific  objectives 

^  Lead  time 

_ A 

ABB  Corporate  Research 

EufoSEPGAT-ee- 1  sn  2 

ik  Itw 
#%WIP 

• 
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Winifred  Mcneies,  ABB  Corporate  Reiearch  & 
Bernhard  Eschermaim,  ABB  Switzerland 


Setting  Up  SPI  In  a  MuHicidtiiral  and 
Decentralised  Engineering  Company 


TOPP  organisation  I 


19  companies 

Contact  person  at  each  company 


r 


T9>PP 

V _ y 

3  people  central 
TOPP  groupp 

•  Management 
consultants 

•  Corporate  Research 

•  Rotating  company 
representative 


ABB  Corporate  Research 


EuroS£PG«7-eS-f«rt3 


Target  audience  for  TOPP 


ABB  Corporate  Research  KlE 

EufaSCPG«7-0«'l«n4 
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Winifred  Mcnezes,  ABB  Corporate  Research  & 
Bernhard  Eschermann,  ABB  Swilzeriand 


Setting  Up  SPI  In  a  MuHicuftural  and 
Decentralised  Engineering  Company 


T3PP  planning  | 

Vision;  ABB  has  world  class  software 
development  in  2000 

• 

Work  backwards  from  vision  to  objectives  and 
activities  99,  98,  97 

• 

Objectives  and  activities  for  process,  technology, 
competency  (people)  and  communication/acceptence 

• 

The  TOPP  4  -  companies  with  maturer  software 
processes  commited  to  being  role  models 

Support  interests  of  all  TOPP  companies  ^ 

ABB  Corporate  Research  Jk  BkSk  1 

Planning  Tool 


ABB  Corpora^^Research'^* 

£uraaEPO«r4».i«rtt 


1999 


ABB 
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Winifarcfi  Mcnczcs,  ABB  Corpariitc  Research  &  Setting  Up  SPI  In  a  Multicultiiral  and 

Bernhard  Eschermann,  ABB  Switzerland  Occentr^ised  Engineering  Company 


TC^PP  Activities  1997 


Top  management  informed 
Software  processes  understood 
TOPP  4  have  improvement  data 
All  TOPP  companies  have  a  metrics  program 
P-CMM  used  by  at  least  one  of  the  TOPP  4 
Competency  profiles  defined 
T raining  available 

Survey  of  development  tools  and  environments 
Discussion  database  and  WEB-pages 


ABB  Corporate  Research 


EweS£PO«7-06-t«n7 


SWITCH:  Software  process  Improvement  Thrust  for  CH 


■  Getting  management  interest 

-  Early  96;  presentation  to  member  of  executive  board 

-  Summer  96:  data  collection  to  show  importance  of  software  development 

-  Presentation  of  results  to  "cross-company  team  technology’  responsible  for 
technology  coordination 

-  Autumn  96;  proposal  to  and  decision  by  executive  board 

■  Getting  SWITCH  off  the  ground 

-  December  96:  Kick-off  seminar  with  one  representative  of  each  company 

-  January  97:  Decisions  by  companies  to  participate,  responsible  people  named 

-  March  97:  All  companies  have  improvement  programs  in  place 

-  End  of  97:  First  reevaluation  of  activities  continuation  decision 


ABB  Corporate  Research  Jk  Rk 

EureSCPa«74»>1V1« 
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Winiircd  Mcnczes,  AIB  Corporalc  Research  A 
Bernhard  Eschermann,  ABB  Switzerland 


Setting  Up  Sn  In  a  Muhkiillural  and 
Decentr^ised  Engineering  Company 


Goals  of  SWITCH _ 

■  Cor  /-specific  activities,  e.g. 

~  Improved  software  development  processes 

-  Improved  project  planning  and  tracking  (effort,  schedules) 

-  Improved  quality  assurance 

-  Introduction  of  metrics 

■  Swiss  activities 

-  Foster  and  support  company-specific  activities 

-  Keep  management  attention  and  support 

-  Experience  sharing  between  companies 

-  Exchange  of  checklists,  templates,  process  descriptions, ... 

-  Common  seminars,  courses, ... 


ABB  Corporate  Research 


£uraSEPGA7-0ft-l«/i« 


SWITCH  Implementation  Structuie 


company-specific  activities  overall  SWITCH  activities 


ABB  Corporate  Research  KK 
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Winifrtd  Mciwics,  AIB  Corpor^lc  ItcsNrch  A 
BctnKird  Eschcrmann,  ABB  Switzerland 


Setting  Up  Sf  I  In  a  Multicultiiral  and 
Occentraliicd  Engineering  Company 


TOPP  and  SWITCH 


Similarities 

Differences 

Driven  by  Corporate  Research 

No.  of  people  impacted 

Supported  by  member  of  country 
management  board 

Age  of  initiative 

Level  of  country  wide 

Software  not  considered  main 
business 

cooperation 

Degree  of  openess  to  new 

Necessity  of  using  local  language 

ideas  and  central  initiatives 

ABB  Corporate  Research 

Eu>aSEPGi97-0e-i6l31 


Lessons  learnt _ 

Easy  to  say  yes  -  difficult  to  get  real  commitment 
Patience  and  perserverance 
Management  of  expectations 

Need  of  stable  point,  despite  organizational  or  personal  change 
Cooperation  and  open  exchange  of  information,  not  competition 
Allow  for  different  implementations,  with  same  high  level  goals 
Business  needs  must  drive  SPI,  not  CMM 
Use  advanced  parts  of  organisation  to  pull  others  along 

ABB  Corporate  Research 

EuroSePG«7,OS  l•/22 
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The  CepabilitY  MaturitY  M04M  for  Software,  Venion  2 


Soffvwo  bnginMhn^  (natituw 

The  Capability 
Maturity  Model  for 
Software,  Version  2 

Mark  C.  Paulk 
Bill  Peterson 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 

This  work  is  sponsored  by  the  U.S.  Department 
of  Defense. 
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Software  Engineering  Institute 


Topics 


Change  -  Going  to  Version  2  of  the  Software 

CMM 


Using  Templates 

The  Level  2  Key  Process  Areas 

The  Level  3  Key  Process  Areas 

The  Level  4  and  5  Key  Process  Areas 

Conclusion 
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Bill  Pctcnon,  SCI 


The  Cj|Mbility  Maiuriiy  Model  for  Software,  Vtr'ion  2 


Suftwara  En»n— nng  (nsiiUiro 

Drivers  for  SW-CMM  v2 

Address  change  requests  from  users 

Continual  improvement  of  the  SW-CMM 

•  respond  to  growing/changing  needs 

•  improved  understanding  of  “best  practices” 

•  improved  understanding  of  levels  4  and  5 

•  make  the  implicit  explicit 

Harmonize  with  relevant  national  and 
international  standards  (and  other  CMMs) 

•  provide  mappings 

•  minimize  unnecessary  differences 


,  '  a  V  'v-rniv 

Software  Ertgintering  Institute 


CMM  Integration 

Common  CMM  Framework  (CCF)  document  set 
planned  for  release  in  August  1997. 


Software  CMM  v2  is  an  “early  adopter”  of  CMM 
Integration  criteria. 

•  piloting  CMM  Integration  proposals  as  part  of 
the  v2  effort 

•  v2  will  satisfy  CCF  requirements 

•  reassignment  of  resources  significantly 
impacted  Software  CMM  schedule 
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The  Capability  MaluritY  Model  lor  Software,  Version  2 


Sottwar*  Enginoanno  Inatituta 


Global  Changes 


The  name  of  level  4  will  be  changed  from 
“Managed"  to  “Quantitatively  Managed.” 

Key  practices  will  be  rewritten  in  active  voice. 


Templates  will  be  used  systematically. 

•  templates  provide  consistency  and  highlight 
exceptions 
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Software  Engmeerirvg  inthtute 


Key  Process  Area  Changes 

Software  Supplier  Management  at  level  2 

•  major  revision  of  Software  Subcontract 
Management 

Software  Risk  Management  at  level  3 

•  draft  key  process  area  released  for  review 

•  final  decision  on  incorporation  will  be  made 
in  May 

Significant  revision  of  levels  4  and  5 
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The  Capability  Maturity  Model  for  Software,  Version  2 


Softwarm  Bngt/fthng  Institut* 


Other  Significant  Changes 

Focused  Integrated  Software  Management  on 
differences  from  Software  Project  Planning  and 
Software  Project  Tracking  &  Oversight  rather 
than  similarities. 

Expanded  scope  of  Software  Product 
Engineering  on  both  ends  of  life  cycle. 

•  requirements  elicitation  and  systems 
analysis 

•  delivery  and  installation 

•  operations 

•  support 

•  maintenance 


Software  Engineenng  insritute 


Revise  Goals 


Goals  are  primary  SW-CMM  rating  components. 

•  need  to  capture  institutionalization  expiicitly 
in  rating 

Systematically  revise  goals  to  incorporate 
maturity  level  principles. 

•  institutionalization  embedded  in  definitions 
of  maturity  level  principles 

•  implies  replacing  current  "planning”  goals 
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The  CapebBity  Metuiity  Model  lot  Software,  Version  2 


Sultwaro  En^inMnog  lnstitut« 


Systematic  Key  Practice  Changes 

Plan  moved  from  Activity  to  Ability. 

Training  and  orientation  key  practices  combined. 

Measurement  key  practices  reworded  to  focus  on  use 
for  control  and  improvement. 

Review  and/or  audit  key  practices  split  into  process 
assurance  and  product  assurance. 

•  audit  terminology  removed 
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Soltware  Engineering  Institute 

Rejected  Proposals 

Many  proposed  major  changes,  i.e.,  add  a  key 
process  area,  will  be  implemented  as  minor 
changes. 

•  key  practices 

•  subpractices 

•  examples 

Examples  include: 

•  test  management 

•  requirements  eiicitation 

•  packaging,  delivery,  installation,  operations 

•  maintenance 
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Maturity  Level  Principles: 
Organizational  Capability 


Process 

Improvement 


Process 

Control 


Qualitative  Quantitative 


I 


Software  Engineering  institute 


Initial  Level 


Maturity  level  1  implies  software  engineering 
and  management  processes  are  performed  in 
an  ad  hoc  manner. 


No  further  description  of  maturity  level  1  is 
necessary. 

•  broad  range  of  engineering  and  management 
practices  possible 

•  consistency  across  time  and  across  the 
software  organization  problematic 


» 
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The  Capability  Maturity  Model  for  Software,  Version  2 


SoHwi^rii  Engincertny  InstilutA 


Repeatable  Level 

Emphasis  is  on  qualitative  process  control  by 
applying  basic  project  management. 

In  SW-CMM  v1,  we  used  “according  to  a 
documented  procedure”  at  level  2  (and  higher). 

“Perform  {KPA}  according  to  a  repeatable 
process.” 


>  ,a  •  . 

Software  Engineering  Institute 


Defined  Level 

Emphasis  is  on  qualitative  process 
improvement  by  organizational  learning. 

•  build  on  concept  of  “repeatable  process” 

In  SW-CMM  v1,  we  used  “according  to  a 
defined  process”  sporadically,  beginning  at 
level  3. 


Perform  {KPA}  according  to  a  defined  process. 

Perform  {KPA}  according  to  the  project’s 
defined  software  process. 
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Software  Eft9(nMrir^  Inctrfufa 

Quantitatively  Managed  Level 

Emphasis  is  on  quantitative  process  control  by 
the  systematic  use  of  measurement 

•  build  on  concept  of  “defined  process” 

•  implies  management  by  fact,  predictability 

“Perform  {KPA}  to  support  quantitatively 
managed  processes” 


17 


Software  Engineering  institute 


Optimizing  Level 


Emphasis  is  on  continual  process  improvement 
based  on  a  quantitative  understanding  of  the 
implications  of  process  change. 

•  build  on  concept  of  quantitatively  managed 
process 

“Perform  {KPA)  to  support  optimizing 
processes.” 
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Software  fengineering  fncrtituM 


Institutionalization  Goals 

Institutionalization  is  at  least  as  important  as 
implementation  for  building  process  maturity 
and  capability. 

V2  will  have  an  “institutionalization  goal”  for 
each  key  process  area. 

•  capture  the  principle  of  the  maturity  level 
concisely 

•  map  all  of  the  institutionalization  practices 
(i.e.,  Commitment,  Ability,  Measurement, 
Verification) 

•  explicitly  and  separably  capture 
institutionalization  as  a  rating  component 


Software  Engineenng  (nsfirute 


Commitment  to  Perform 

Describes  the  actions  the  organization  must 
take  to  ensure  that  the  process  is  established 
and  will  endure 


Typically  includes 

•  policy 

•  sponsorship  (for  organization  KPAs) 
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Software  Enqti>e«rir^  Inatituta 

Ability  to  Perform 

Describes  the  preconditions  that  must  exist  in 
the  project  or  organization  to  implement  the 
software  process  competently 

Typically  includes 

•  plan 

•  resources  and  funding 

•  responsibility  and  authority 

•  training 


Software  Engineering  Institute 

Activities  Performed 

Describes  the  roles  and  procedures  necessary 
to  implement  a  key  process  area 

Implement  the  institutionalized  process 

Subpractice  templates  for 

•  configuration  management 

•  reviews 

•  peer  reviews 

•  etc. 
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Measurement  and  Analysis 

Describes  the  need  to  measure  the  process 
and  analyze  the  measurements 

Typically  includes 

•  control 

•  improvement 

(level  3  and  higher) 
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Software  En^ineerinq  Institute 


Verifying  Implementation 

Describes  the  steps  to  ensure  that  the  activities 
are  performed  in  compliance  with  the  process 
that  has  been  established 


Typically  includes 

•  process  assurance 

•  product  assurance 

•  project  manager  review 

•  senior  management  review 
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Requirements  Management  BS 
(RM) 

The  purpose  of  Requirements  Management  is  to  establish  a 
common  understanding  between  the  customer  and  the 
software  project  of  the  customer's  requirements  that  will  be 
addressed  by  the  software  project 

Interface  between  software  project  and  "customer" 
is  fuzzy. 

•  systems  engineering 

•  marketing 

•  external  customer 

Important  that  allocated  requirements  be 
documented  and  controlled. 
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9 
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Software  Project  Planning  SS 
(PP,  SPP) 

The  purpose  of  Software  Project  Planning  is  to  establish 
reasonable  plans  for  building  the  software  product  and  for 
managing  the  software  project 

“Plan  the  plan"  was  a  controversial  template  to 
apply. 

•  concept  is  valid,  although  may  be  out  of  scope 


Sof1w«r«  Ef>9fntnrtg  lifstitut* 


Software  Project  Tracking  Dg5 
and  Oversight  (PT,  PTO) 

The  purpose  of  Software  Project  Tracking  and  Oversight  is  to 
provide  adequate  visibility  into  actual  progress  so  that 
management  can  take  effective  actions  when  the  software 
project's  performance  deviates  significantly  from  that 
planned. 

Key  practices  changed  to  make  PTO  more 
consistent  with  SPP. 
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Softwar*  EnginMnng  IfurtftuM 

Software  Supplier  Management  QS 
(SM,  SSM) 

The  purpose  of  Software  Supplier  Management  is  to 
effectively  manage  the  acquisition  of  software  obtained 
externally  to  the  software  project 

Major  expansion  of  vl.l’s  Software  Subcontract 
Management  KPA  to  include  non-developmental 
software  included  in  product 

•  commercial-off-the-shelf  software 

•  customer-supplied  software 

Tools  in  software  engineering  environment  is 
considered  a  risk  rather  *han  in  scope  of  this  key 
process  area. 
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Software  Quality  Assurance  QS 
(QA,  SQA) 

The  purpose  of  Software  Quality  Assurance  (SQA)  is  to 
ensure  that  the  software  project's  activities  and  work 
products  comply  with  the  applicable  requirements,  process 
descriptions,  standards,  and  procedures. 

Lowered  die  visibility  of  die  SQA  group. 

•  alternative  implementations  in  some 
organizations 

Separated  process  and  product  assurance 

•  SQ>4  goals 

•  Verification  practices 
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Software  Configuration  SS5 
Management  (CM,  SCM) 

The  purpose  of  Software  Configuration  Managentent  (SCM)  is 
to  estabiish  and  maintain  the  integrity  of  the  products  of  the 
software  project  throughout  the  software  life  cycle. 

Terminology  remains  a  challenge. 


Softw«r«  Ert^irtMrirtg  Irttfitutft 


Topics 


Change  -  Going  to  Version  2  of  the  Software 

CMM 


Using  Templates 

The  Level  2  Key  Process  Areas 

The  Level  3  Key  Process  Areas 

The  Level  4  and  5  Key  Process  Areas 

Conclusion 
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Softwar*  Enginaaring 

Maturity  Level  3  Issues 

Using  “defined  process”  versus  “project’s 
defined  softuraire  process” 

Distinguish  between  level  3  concepts  and  level 
2  concepts  (particularly  in  Integrated  Software 
Management) 
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Software  Engineering  Insfimte 


Organization  Process  Focus  Pgg 
(PF,  OPF) 

The  purpose  of  Organization  Process  Focus  is  to  establish 
and  maintain  an  understanding  of  the  organization's  software 
processes  and  coordinate  the  organization's  software 
process  improvement  activities. 

Should  the  focus  be  “software  process 
management"  or  "software  process 
improvement?” 
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Suftwaro  kingineerin^  tnvtituta 

Organization  Process  Definition  B 
(PD,  OPD) 

The  purpose  of  Organization  Process  Definition  is  to 
establish  and  maintain  a  usable  set  of  software  process 
assets  that  improve  process  performance  across  the 
organization,  and  provide  a  basis  for  cumulative,  long-term 
benefits  to  the  organization. 

Set  of  standard  software  processes  for 
organization 

Changed  “organization’s  software  process 
database’’  to  “organization’s  software 
measurement  database.  ’’ 

•  placed  under  change  control 


.  '  »  V'  s 

Software  Enqir^eering  tnafitute 


Organization  Training  Program 
(TP,  OTP) 

The  purpose  of  the  Organization  Training  Program  key 
process  area  is  to  develop  the  skills  and  knowledge  of 
individuals  so  they  can  perform  their  software  roles 
effectively  and  efficiently. 


Re-focused  on  organizational  training  perspective. 

Name  change  to  include  “Organization"  also 
applies  to  other  key  process  areas  at  higher  levels. 
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Software  bngirreeriny  Institute 

Integrated  Software  Management  BSE 
(IM,  ISM) 

The  purpose  of  Integrated  Software  Management  is  to 
integrate  the  software  engineering  and  management 
activities  into  a  coherent,  defined  software  process  that  is 
tailored  from  the  organization's  standard  software  process 
family,  which  is  described  in  the  Organization  Process 
Definition  key  process  area. 

Revised  to  focus  on  level  3  nature  of  planning  and 
managing  software  projects. 

•  emphasize  differences  with  level  2  mther  than 
similarities 


Software  Engineering  insfilute 

Software  Product  Engineering  BS5 
(PE,  SPE) 

The  purpose  of  Software  Product  Engineering  is  to 
consistently  perform  a  well-defined  engineering  process  that 
integrates  all  the  software  engineering  technical  activities  to 
produce  correct,  consistent  software  products  effectively 
and  efficiently. 

"Software  engineering"  includes  management 
practices;  “software  product  engineering”  is 
Jargon... 

Expanded  to  capture  overall  life  cycle. 


(C306b)  S-19 


SufhtvMre  ^nqinvering  Institute 


Intergroup  Coordination  (IC) 


The  purpose  of  Intergroup  Coordination  is  to  actively 
participate  with  the  other  groups  involved  in  the  software 
project  to  address  the  system-level  and  intergroup 
aspects  of  the  project  in  order  to  better  satisfy  the 
customer's  needs. 

Still  has  bias  towards  “groups”  that  we’ve  tried 
to  remove  or  demote  elsewhere. 

•  renaming  as  “Collaborative  Work”  proposed 

Still  written  from  software  perspective. 


SoUwsre  Enqinsermg  Insfifuls 


Peer  Reviews  (PR) 


The  purpose  of  Peer  Reviews  is  to  remove  defects  from 
the  software  work  products  early  and  efficiently.  An 
important  corollary  is  to  develop  a  better  understanding 
of  the  software  work  products  and  of  defects  that  might 
be  prevented. 


New  goal:  “Establish  a  shared  understanding 
of  the  software  work  products  through 
participation  in  peer  reviews.” 
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Software  Risk  Management  SS 
(SR,  SRM) 

The  purpose  of  Software  Risk  Management  is  to  identify  and 
mitigate  software  risks  throughout  the  life  cycle  of  a  software 
product. 

The  most  controversial  proposal  in  Draft  A... 

If  adopted,  the  risk  management  goals  and  key 
practices  in  ISM  will  be  deleted. 

Decision  will  be  made  in  May  at  joint  CMM 
Advisory  Board/Software  CMM  Change  Control 
Board  meeting. 
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Topics 


Change  -  Going  to  Version  2  of  the  Software 
CMM 


Using  Templates 

The  Level  2  Key  Process  Areas 

The  Level  3  Key  Process  Areas 

The  Level  4  and  5  Key  Process  Areas 

Conclusion 
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In  Process... 

Maturity  levels  4  and  5  are  still  under 
development 

•  key  process  area  names  will  change! 

Using  the  templates  consistently  and 
meaningfully  at  levels  4  and  S  is  challenging. 

•  for  example,  “Perform  quantitative  process 
management  according  to  a  quantitatively 
managed  process.” 

The  level  4  and  5  key  process  areas  will  be 
distributed  in  Draft  B’. 


Sohware  Engineering  Institute 


Clarify  Level  4 


Major  focus  is  clarifying  the  rigorous  and 
systematic  use  of  statistics  at  level  4. 

•  quantitative  management  is  more  than  just 
measurement 

•  understanding  what  data  means  -  what  to 
control  and  what  not  to  control 


Proposed  level  4  key  process  areas 

•  Statistical  Process  Management 

•  Organization  Process  Performance 

•  Organization  Product  Alignment 


«4 
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Build  on  Quantitative 
Understanding  of  Process 

Need  to  communicate  that  level  5  builds  on 
level  4  capability. 

•  concepts  of  measurable  improvement,  agility, 
innovation  poorly  expressed 

Prop'ised  level  5  key  process  areas 

•  Inct  emental  Improvement 

•  Innovative  Improvement 

•  Process  Opportunity  Analysis 

•  Participative  Deployment 


Software  Engineering  institute 


Topics 


Change  -  Going  to  Version  2  of  the  Software 
CMM 

Using  Templates 

The  Level  2  Key  Process  Areas 

The  Level  3  Key  Process  Areas 

The  Level  4  and  5  Key  Process  Areas 

Conclusion 
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Drafts 

Draft  A  is  now  available  for  review  and  pilot 
testing. 

•  level  2  and  3  key  process  areas 

Draft  6  will  contain  the  level  4  and  5  key 
process  areas. 

•  two  separate  releases:  B’  and  B 

•  selected  front  matter  and  appendices 

•  incorporate  draft  CMM  integration  criteria 

Draft  C  will  be  the  “final  draft.” 

•  additional  drafts  may  be  necessary, 
depending  on  feedback  received 


Software  Engineering  institute 


For  Additional  Information 


Telephone  412/268-5800 
Fax  412/268-5758 


Internet  customer-relations@sei.cmu.edu 

U.S.  mail  Customer  Relations 

Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213-3890 

Web  page 

http://www.sei.cmu.edu/technology/cmm 
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Systems  as  humanity! 


We  spend  most  of  our  life  cycle  in  a  stage  called  “Maturity" 


Systems  spend  most  of  theirs  in  a  stage  called 
“Maintenance” 


“Legacy"  is  a  stage  of  the  maintenance  cycle 


What  are  the  Classes 
of  Maintenance? 

•  Perfective 

-  Enhancements  to  meet  changing  business 
requirements  or  functions;  business>driven 

•  Adaptive 

-  Upgrades  to  meet  changing  technical 
requirements  or  functions;  technology-driven 

•  Preventative 

-  Improving  quality,  reliability,  maintainability 
and  preventing  errors  from  occurring;  a 
proactive  process 

•  Corrective 

-  Fault  diagnosis  and  correction;  a  reactive 
process 
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Within  these  ciasses  we  have  choices 


Discretionary 

•  Prioritised  business 
enhancements 

•  A  new  operating  system  feature 

•  The  Millennium 

•  Minor  irritating  problems 
Non-discretionary 

•  Regulatory 

•  Audit/compliance 

•  External  agencies 

•  Head  Office  needs 


Perfective 

Adaptive 

Preventative 

Corrective 


L. 


It  will  help  focus  your  management  of  maintenance,  and  thus 
“legacy”,  if  you  can  construct  your  plans  to  reflect  these  classes 


Ten  Ticklist  Topics 

•  System  is  subject  to  active  perfective  maintenance 

•  Majority  of  perfective  maintenance  is  discretionary 

•  System  is  subject  to  active  adaptive  maintenance 

•  Majority  of  adaptive  maintenance  is  discretionary 

•  System  is  subject  to  active  preventative  maintenance 

•  Development  productivity  improving 

•  Internal  quality  improving 

•  Simple  integration  with  other  technologies 

•  Reuse  at  least  30% 

•  Active  market  in  development  skills 


Against  how  many  of  these  can  you  place  a  tick? 
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The  Four  Stages  of  Maintenance 

•  Endowment:  tick  10  -  6 

•  Heritage:  tick  7  •  5 

•  Legacy:  tick  4-2 

•  Liability  tick  1-0 

Longer,  and  better  quality,  life  cycle  with  higher 
maintenance  investment;  systems  which  are:- 

Strategic,  long-term  business  operations 

Critical  business  functions 

Subject  to  rapid  technology  evolution 


Any  questions? 
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You  take  too  long 
and  cost  too  much! 
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Projected  Productivity  for  Legacy  Systems 
“Perceived  Wisdom”  Q1/1992  =  100 
.  Increase  in  application  size  and  complexity 
.  Adverse  pressure  on  design  and  code  quality 
.  Increasing  business  pressure 


12341234123412341234 
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strategy  Decision  - 1990  -  SPI 

Process,  Product  and  People  Improvement 

•  Establish  measures,  publish  to  IT  and 
business 

•  Improve  software  quality 

•  Declare  the  mainframe  development 
environment  “Legacy” 

•  Invest  in  new  development  technologies 

•  Endow  the  GBS/IMS  system  through  into  the 
new  millennium 

•  Ensure  millennium  compliance 

•  Evolve  the  ability  to  integrate  with  emerging 
and  converging  technologies 


Prelect 

Management 

Process 
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Business  Responsibility 


IT  Responsibility 
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Global  Banking  System 
Some  general  information 

iMS/TM 

Some  25,000  “components” 

6,000  COBOL  component 

1,600  AOF  components 

110+  physical  databases;  250+  db  datasets 

Across  each  of  10  IMS  “hosts” 

40  countries  supported 
“The  sun  never  sets”;  7-day  x  24-hour 
15-17,000  changes  per  year;  70  projects 
Consolidated  change  every  month 
Developer  population  c.  40 
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Development  Environment 
Mainframe  -  VM/ISPF  Clients, 
VM  and  MVS  Servers 


•  Productive  platform,  but:  plenty  of  text  editing 

•  No  ability  to  integrate  workstation  tools 

•  A  large  list  of  required  enhancements 

•  Sound  basic  client/server  architecture 

•  Classified  as  “Legacy” 


Development  Environment 
"The  New"  is:- 

•  The  COBOL  quality  programme 

•  Developer  2000 

-  Developer  LAN 

-  Simple  application  population 

-  Complex  application 
population 

•  ADF  migration 

-  Developer  Dialogue 


Developer  2000 
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Development  architecture 
The  “Software  Factory” 


Workstation  services 

LAN  services 

Mainframe  services 

os/j  ■ 

Token  rino/Novell 

VM 

Hys 

3270  emulation 

Netware  wSAA 

ZSPPS 

CiPPA 
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f  Imoacf  analysis 
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1  Impact  analysis  )l  LIBRARIAN  I 

1  Office  automation 

Meesage  Manager 

I  Mail  WAN  1 

Protect  control 

Protect  Regositorv 

1  Reference  manuals 

BookManaqer 
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Global  Systems  Development 
Key  Performance  Measures 


Key  Performance  Measures 
What  is  a  "component"? 

•  It  is  a  piece  of  GBS  which  passes  through  the 
Production  Release  System,  where  it  can  be 
counted,  as  we  do  a  release  each  month. 

•  It  is  a  basic  building  block  which  everybody 
understands,  and  which  has  remained 
constant  over  time,  e.g:- 

-  A  COBOL  module 

»  COBOL  COPYbooks 

-  An  AOF  transaction 

»  AOF  dynamic  rules 

»  AOF  Special  Processing  Routines 

-  A  JOB 

»  A  PROCedure 
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Iniprovemeni  at  the  hharp  tnd 


Any  questions? 


(Internal  Measures!) 


Business  Partner 
Quality  Survey 
“TRACK” 
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Legacy 


ADF  Migration/  “Open  GBS” 


Static  Rules 

“Closed” 

Dynamic  Rules 

SPRs  (COBOL) 

Audit  Exits  (COBOL) 

ADFTransaction  Model 

C  Generate  J 

J 

Model 

(Mainframe) 

1  ADF3270  Transaction 

ADF  Migration/  “Open  GBS 


tr 
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3270 


ADI 


GBS 

Business 

Function 


How  do  we 
move  this 
object? 

How  do  we 
give  it  meaning 
to  “the  Legacy”? 


But  we  don’t  want 
to  talk  “3270”. 

What  have  we  done 

We  have  used  about  the  “closed”  GBS? 

Messaging 

Middleware  We  have  made  it 

OPEN! 


The  object  boys  call  this 
a  “flattened”  object! 


3270 


Facilitated  by 
ADF  Migration. 

The  same  functions 
for  Open  Interface. 
GBS  as  a  Server  with 
1,600  Stored  Procedures 


OBS 
Model 


GBS  -  the  Open  Perspective 

Integration  of  many  technologies 


Final  questions? 


ai  Utc  Liiu 
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Experiencing  Software 
Process  Improvement 
at  the  Sharp  End 


Paul  Hookham 

Head  of  Project  &  Technical  Services 
Information  Systems 
Lloyds  TSB  Group 
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Agenda 


•  Today's  Objectives 

•  About  our  company 

•  Reasons  for  SPI  in  Lloyds  /  TSB 

•  Some  Mistakes 

•  Good  Practice 

•  Curved  Balls 

•  Successes 

•  Blueprint  - 10  Critical  Success  Factors 

•  What  Next? 
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Today’s  Objectives 


A  Personal  Viewpoint 

•  Resistance  encountered 

•  Interesting  behaviour 

•  What  didn't  work 

•  What  worked  well 
Some  things  to  watch  out  for 
Why  it's  working  now 
The  Next  Steps 


About  our  company 


•  Provision  of  Financial  Services 

•  Lloyds  /  TSB  merged  28  December  1995 

•  2,810  High  Street  branches 

•  82,000  employees 

•  Group  assets  :  £147  billion 

•  Top  5  UK  quoted  company  with  a  market 
capitalisation  of  £33  billion  (11/05/97) 

•  Merger  benefits  to  be  accrued 

•  Significant  other  challenges  ahead 

M  Ik**  TM  0)«w  ~  I  n  r  '*"•  «tl7 
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Reasons  for  SPl  in  Lloyds  /  TSB  000 


Productivity  -  (Function  Point  per  £) 

•  Predictability  -  (Function  Point  per  month) 

•  Flexibility  &  Responsiveness  -  (Resource  Pools) 

•  Demonstrate  competitiveness  -  (Assessments) 

•  Improve  Defect  Detection  &  Removal  Rate 

-  (Inspection) 

Improve  Benchmark  position  -  (Credibility) 
Focus  on  the  Quality  System 
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Improvement  at  the  Sharp  tnd 


Some  Mistakes 


•  Lack  of  skilled  resource 

•  Tick  in  the  box  mentality 

•  Lack  of  ownership 

•  Inadequate  training  /  awareness 

•  Too  concerned  about  Business  Case 

•  Too  concerned  about  Automation 

•  Resistance  -  No  targeting  policy 

•  Did  not  win  hearts  &  minds 


•eianaMfwn.  ijet«r$8&eu«  tmeeeewg^  ■» 


»I.Dy«e8MawtT8»0ieiwME  mr 


4 


4 


4 


4 


t 


More  Mistakes 


•  Too  Many  Wise  Men 

•  SPl  or  Product?  -  your  choice 

•  Executive  Commitment  waned 

•  Consultants  -  succession  plans? 

•  Many  gaps  after  2Q96  assessment 

•  Not  seen  as  important  -  no  impact  on  PRP 

•  Early  Adopters  /  Early  Majority  Chasm 


1 


f 


4 


i 
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n’t  worry  -  it  will  go  away  soon' 


Successes 


[Configuration  Management 


Requirements  Management 


Risk  Management 


FULL  TIME  INVOLVEMENT  IS  KEY 


<yiB>«wgl>0  jum  <m/ 


More  Successes 


Realistic  Scheduling 


Senior  Management  Commitment 


Project  Awareness 


Intro  to  CMM  -  3  day  training 


•  k.»V<i*w*MeiTSBOrai«p«c  imr  MgMvi* 
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Blueprint  -  10  Critical 


•  STEP  1 

ESTABLISH  SENIOR  MANAGEMENT 
STEERING  GROUP:  - 


SET  POLICY 

LAUNCH  TRAINING  &  COMMUNICATIONS 
MONITOR  PROGRESS 
PUBLICISE  BUSINESS  GOALS 


Blueprint  - 10  Critical 


•  STEP  2 

ESTABLISH  SENIOR  MANAGEME 
COMMITMENT:  - 


INTERNAL  COMMUNICATIONS 
SOCIAL  EVENTS 
TRAINING  COURSE  DINNERS 
PUBLICISE  SPI  AT  EVERY  OPPORTUNITY 


I  (bow  SPC  AM  IMT 


•  «  T»  PC  tnr  M  nr 
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Blueprint  - 10  Critical 
Success  Factors _ 


•  STEP  3 

ESTABLISH  AN  AGREED  TRAINING 
AND  ASSESSMENT  SCHEDULE  WITH 
SENIOR  MANAGEMENT  &  IMPLEMENT  IT 

•  STEP  4 

MANAGEMENT  TEAMS  ATTEND  TRAINING 
AND  PRODUCE  ACTION  PLANS  FOR  GAP 
CLOSURE 


Blueprint  -  10  Critical 


•  STEP  5 

MANAGEMENT  TEAMS  PRESENT  THEIR 
ACTION  PLANS  TO  THEIR  TEAMS  &  DELIVER 
CMM  OVERVIEW  TO  THEM  -  TO  SHOW 
OMMITMENT 


ft  rSCAftft  t\imm  n  MW. An*  ’W> 
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Impruvement  at  the  Sharp  tnd 


Blueprint  -  10  Critical  000 


STEP  6 


SCHEDULES  FOR  IMPLEMENTATION 
OF  ACTION  PLANS  ARE  PRODUCED 
3-4  WEEKS  AFTER  TRAINING 


FORWARDED  TO  SEPG  FOR  TRACKING, 
CONSOLIDATION  &  ONWARD  SUBMISSION 
TO  STEERING  GROUP 


Blueprint  -  10  Critical 
Success  Factors _ 


•  STEP  7 

ISSUES  AND  PROGRESS  ARE  TRACKED 
AND  MONITORED  BY  STEERING  GROUP, 
VIA  STANDARD  PROGRESS  REPORTING 


•  STEP  8 

EXTERNAL  CBA-IPI,  BY  FUNCTION,  3-4 
MONTHS  AFTER  TRAINING  USING  SEI 
LEAD  ASSESSOR 


Wednesday  18  lune 


(C307a)S-10 


inipruvement  4I  lh«  Sh^rp  knd 


Q  Blueprint  -  10  Critical 

•  STEP  9 

REVISE  ACTION  PLANS  AND  SCHEDULES 
TAKING  INTO  ACCOUNT  ASSESSMENT 
FINDINGS 


•  STEP  10 

PERFORM  AN  INTERNAL  RE-ASSESSMENT 
6-9  MONTHS  AFTER  EXTERNAL  CBA-IPI 


What  Next? 


Automation 

Software  Acquisition  CMM 
Train  the  Trainer 
Internal  SEI  Lead  Assessor 
Sub  Contractor  Evaluations 
Peer  Reviews 

WHO  KNOWS  ? 


•.  UJb»*  TM  Ona*  Im 
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ARE  YOU  GOING  MAD? 


ONE  FINAL  THOUGHT  FROM  ANON. 


'INSANITY  EXISTS  WHEN  YOUR 
MANAGEMENT  EXPECT  YOU  TO  REPEA  T 
THE  SAME  PROCESS  OVER  AND  OVER  AND 
OVER  AGAIN  BUT  GET  DIFFERENT  RESULTS 
EVERY  TIME' 


European  SEPG  -  June  18,  1997 


Requirements  for  Winning 
Software  Teams 


Bill  Curtis 

TeraQuest  Metrics 
Austin,  Texas 
& 

Software  Engineering  Institute 
Carnegie  Mellon  University 


This  talk  can  be  accessed  at  http://www.teraquesLcoin 


KL  TeraQuest 


Wwinme  SW  Tswm  I 

S  1M7  TeraQuMt 


From  Individuals  to  Teams 


This  presentation  assumes  there  is 
a  progression  of  steps  through 
which  many  organizations 
must  pass  to  install 

empowered  wori<group. 


Individuals 


'T 

•1C.  TeraQuest 


Teams 


Team-based 

organization 


Traditional  y)^j3 

organization  progression 

underlies  the  staging 
of  some  key  practices,  key 
process  areas,  and  maturity  levels 
in  the  People  Capability  Maturity  Model 


WinnM»9  SW  Teem 
•  1M7  T*f»QuMt 
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Initiating  Software  Teams 


Select 

structure 


Identify 

competencies 


^TeraQuest 


Team  formed  from 
complementary 
mix  of  skills 


iSH 
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Characteristics  of  Teams 


Empowered  —  “...they  do  not  have  to  go  through 
hierarchical  approval  for  many  of  their  decisions 
about  how  to  do  their  work.”  (Mohrman  et  al.,  1995) 

Self-IManeged  —  “...they  perform  for  themselves 
many  of  the  tasks  that  management  used  to 
perform...”  (Mohrman  etal.,  1995) 

Warning  —  empowerment  and  self  management 
do  not  mean  that  teams  are  free  to  pursue  their  own 
agendas.  With  empowerment  comes  responsibility. 

S.  Mohrman,  S.  Cohen,  X  A.  Mohrman  (1995).  Designing  Team  Based  Organizations. 
*1*.  San  Francisco:  Jossey-Basa.  _ 

K.TeraQuest  9 

'-mmmmmmammmmmmmmmmmamamsmagamammmmm 


Empowered  Execution 


Provide 

facilitation 


Tailor 

standard 

processes 


Establish  relationships 
with  other  teams 


Plan 

commitments 


Define 

measures 


^TeraQuest 


10 


Wmnmg  $W  Teems 
•  1M7  TereQueet 
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Providing  Standard  Team  Processes 


Teams  should  be  given  a  process  they 
can  tailor  rather  than  be  forced  to 
thrash  for  months  creating  their  own 


P^TeraQuest 


TQ 

eam%# 


oftware  ■  rocess 


coming  from  Watts  this  August  at  the  SEI  Symposium 


Winning  SW  Ttamt 

f)  1997  T»r»Ou*»i  I 


Team  Workforce  Practices 


Workforce  practices 
adjusted  for  use 
with  teams 

V 


RkTeraQuest 


Team*Based 

Workforce 

Practices 

Team  recruiting 
Selection  methods 
Team  orientation 
Performance  mgt. 
Training  needs 
Compensation 
Workforce  planning 

12 


»  r. 

m  Mi 


Team  members 
involved  in 
performing 
some  practices 


Winning  SW  Teams  ^ 
S  1997  TeraQuest  1 
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Team  Performance  Management 


Team 

performance 

criteria 


Supervisory  input 
and  awareness 


Team 

performance 

review 


Team 

recognition 
and  reward 


Team 

development 

needs 


Compensation 

decisions 


^TeraQuest 


Wtrtmng  SW  Ttamt 
» tM7  TtraOutti 


Team-Based  Compensation 


Performance 

discussion 

Team 

individual: 

•  personal  performance 

-  competency  growth 

-  contribution  to  team 


Recognition  or  reward  ! 
— ^  [compensation  decisionl 


Compensation  Strategy 

Motivate  performance  alignment: 

•  Organizational  performance 

•  Unit  performance 

•  Team  performance 

•  Individual  performance 


PILTeraQuest 


Winning  SW  Team*  i 
<t  1947  TeraQuest 
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1 1ntroduction 


♦  1 986- 1 996:  a  decade  of  SPI  in  large 
companies 

♦  results  and  consequences: 

-  experiences,  loiowledge 

-  mature  SPI  and  SP  assessment  models 

-  higher  quality  criteria  on  SW  market 


I 

i 

Types  of  small  companies 

;■  ■  ■  ■■■  . '  1 

♦  definition  of  term  “small  company”:  I 

depends  on  type  of  company 

-■ 

♦  Types  of  small  companies: 

-  branch  company 

-  independent  company 

-  IT  department  within  enterprises 

Wednesday  18  June 


(C307c)  S-2 


Univcr$ity  of  Maribor 


SPI  in  *  Small  Con^)My 


Types  of  small  companies... 


'  Branch  company 


♦  establishment:  supported  by  partner  -  large 
?  company 

-  financing, 

-  equipment, 

-  training 

*  SPI  projects  conducted  according  to  policy 
i  of  large  company 

j  -  defined  procedures,  required  results  of  each 

;  procedure 


Types  of  small  companies ... 

I  Independent  company 

'  i  ~  '•iiiiii>[w<ii~~MMWiriiiriMfiiiiiiiiwMTiiiTriiaMMitiiaiffiiriiiiiiiinriiii  lim  iim 

I 

'  I 

I  *  establishment; 

-  enthusiasm  of  individuals, 

-  insufficient  budget,  equipment,  . . . 


No.  OF 

Size  OF  Company 

Employees 

up  to  IS 

small  independent  company 

15  to  so 

medium-sized  independent  company 

over  so 

large  independent  company 
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Types  of  small  companies  ... 

IT  department 


♦  organizational  unit  within  enterprise 

♦  process  of  work  is  defined  within  IT 
department,  but  it  should  be  compliant  with 
global  policy  of  enterprise 

♦  customers:  other  departments  within 
enterprise 


Challenges  for  SPISC 

♦  great  dependency  on  individuals 

♦  disposition  of  roles 

♦  large  impact  of  the  human  factor 

♦  dependence  on  few  projects 

♦  importance  of  communication  with 
customers 

♦  difficulties  with  investing  into  SPI 
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\  PROCESSUS  SPISC  model 


i  ♦  models  for  SPI  in  small  companies  (SPISC) 
I  should: 

!  -  be  easy  to  understand 

!  -  provide  firm  guidance  using  a  supporting 

;  documentation 

-  provide  SPI  results  compliant  with  market 
requirements 


PROCESSUS  SPISC  model... 

Background 

.  . . •  _ ..  .;.L  ..-r  : 

:  ♦  based  on: 

.1 

-  detailed  comparison  and  integration  of 
;  ISO  900 1 ,  ISO  9000-3  (ISO  model)  and  CMM 

I  -  experiences  with  SPI  in  small  companies 

■ 


% 
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SPI  m  a  Small  Company 


,  PROCESSUS  SPISC  model... 


Comparis< 

on  of  ISO  model  and  CMM 

Maluniy  levd  m  CMM 

1  RM 

]  Key  process  area 

□ 

4  1  \ 

Tn - 

B 

U7  •  lUHJUUtcv  detne  tor  the  a^iviiv 

\ 

“TTl - 1 

■1 

■ 

M 

1  _  Respective  clause  from  ISO  9000-3 

E 

i 

WiM 

II 

’  *  ^  1  ilein  No  for  the  artwity 

1 

TT! - 

I 

<!1>  \alue 

Meaning 

.Activity  IS  defi’ted  only  in 

1  :  Aciistty  IS  JefinoJ  io  both  moilds  althoui^  OIM  is  more  extensive. 

0  '  Acti\it>  IS  equaOy  defined  in  bothmodeK 

'  1  1  .Xciivirx  is  detifwd  in  both  nodcls  but  1^^  adds  new  aspects. 

-- 

.  \c7iut)  ts  defined  only  IO  model  | 

PROCESSUS  SPISC  model... 

Integration  of  ISO  model  and  CMM 

♦  According  to  the  results  of  comparison 

-  new  KPAs 

-  new  activities 

-  enhanced  activities 

are  incorporated  into  framework  of  original 
CMM 

♦  Characteristics  of  small  companies  require 
change  of  sequence  for  some  KPAs 
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SPl  in  a  Small  Company 


PROCESSUS  SPISC  model.. 

Introduction  phase 


£ isi;:  t 


assignment  and  training  of  quality  manager 
definition  of  SPI  plan 
definition  of  organizational  structure 

♦  definition  of  process  documentation  structure 

♦  introduction  of  SPI  concepts  to  personnel 

♦  definition  of  few  simple  metrics 


,  PROCESSUS  SPISC  model... 

!  Process  definition  phase 


I  ♦  Customer  relationship  management 

—  contract  management 

-  requirements  management 

i  -  product  delivery 

^  -  maintenance 


1-  ,  .VsL 


I  ♦  Project  management 


-  project  plan 

-  quality  management  activities 

-  reviews  of  input  and  output  of  phases 
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„  PROCESSUS  SPISC  model... 

4  "  ■{ 

!  Process  definition  phase 

i 

j  ♦  Software  engineering 

-  definition  of  procedures  for  software 

]  engineering,  considering  used  methodologies 

I  and  tools 

^  ♦  Supporting  activities 

!  -  training 

;  -  document  control 

-  included  product  management 


,  PROCESSUS  SPISC  model... 

’  Process  optimization  phase 

• 

..  _ •  . . s  .:.j 

♦  Process  management 

• 

:  -  metrics 

-  internal  reviews 

1 

'  -  corrective  actions 

• 

♦  Process  automation 

-  supporting  and  automation  of  activities  - 

!  internal  applications,  groupware,  etc.. 

-  PSEEs  (Process-centred  software  engineering 

;  environments) 

\ 

\ 

• 
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PROCESSUS  SPISC  model... 

Process  documentation 


!  ♦  structure: 

i 

j  -  QM  -  Quality  Manual 
!  -  SP  -  Standard  Procedure  ( 1 7) 

-  SD  -  Standard  Documents  (forms,  templates, 
manuals  -  app.  2  for  each  SP) 


SlaailanJ 

Procedure 

Siaadard  llomaeat 

' 

C  Ollll3Ct 

Muuuiueineni 

f  1  ontraci  (e^icw  checklist 

T  C  oniracl 

" 

k««|uirei>ient% 

(TianagtfinetK 

1-  Requirements  chani^e  request 
r  Requiremems  speci/icatiun 

' 

I'roduct  Oelivefv 

E  Acceptance  checklist 

P  .Acceptance  report 

Mumienancc 

P  Maintenance  request 

P  Maintenance  report 

,  PROCESSUS  SPISC  model... 

i  Disposition  of  roles 

,  - . ’  .  . . .  .i-i. 

I-  . . .  ...  . 

M- manager  D  -  developer 

PM  -  project  manager  pc  -  developer  coordinator 

QM  -  quality  manager 


No, 

Standard 

Procedure 

- 1 

Implcm 

eotator 

Assistant 

/Adviser 

Quality 

controller 

' 

Contract 

management 

M 

vKryw 

DM 

“ 

Requirements 

management 

TM 

■RTH 

t>M 

3 

Product  Delivery 

T5 

TW 

OM.  M 

i _ 

Maintenance 

15 

TM 

OM 
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1  Conclusion 


♦  Process  definition  and  application  in 
projects:  app.  18  month 

♦  Influence  of  human  factors  on  the  SPI 
project  is  important 

♦  Process  and  project  documentation  are 
significant  burden  -  the  need  for  support  and 
automation  is  cn  ident 
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Approaches  to  Process  Improvement  Support 


Embedded  Software  in  Philips 


°  2500  -  3500  Software  Engineers  in  1 10  Groups 
a  Fast  Growing  in  Complexity 
a  Maturity  varies  from  Level  1  to  Level  3 
a  Have  experienced  several  Software  Crises 
a  Application  Areas  vary  from  Software  Systems; 

Video  Communication, Telecom.  Medical, . . . 
to  Software  Products: 

Speech  Processing 
to  Firmware: 

Television.  Audio.  Set  Top  Box,  Cameras . 


PHILIPS 


PHILIPS’  SPI  Approach 


Management  ]  Define 
/Awarenessy"^  Objectives,  [ 
" — ^  Targets  I 


General 

Agreement 


Conditioning 


Improvements  can  he 
taken  from: 

-  Process 

-  People 

-  Architecture 

-  Technology 

-  Organisation 


Assess 

Current 

Situation 


Evaluate 

Results 


Define 

Improvement 
Plan _ 


Implement 

Improvements 


Improving 
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Overall  Targets  1997 

Software  quality 

Improve  current  Post-release  and  Final  Test  Defect 
Density  by  factor  2 

Software  maturity 

Improve  at  least  one  CMM-level 

Software  education 

Participation  in  2-day  workshop  ‘Software  Business’  for 
management  teams  where  software  is  strategic 

g  PHILIPS 


(  PHILIPS  CTO  is  Chairman) 

□  SPI  Steering  Committee  (operational  Tasks) 
Q  SPI  Management  at  PD  Level 
°  SPI  Coordination  at  BU  Level 
o  SPI  Steering  Committees  at  BU  Level 
o  SPI  Consultation  in  Philips’  Origin 
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Approaches  to  Process  Improvement  Support 


Philips’  SPI  Support 

n  The  Business  Unit  is  the  Owner  of  the  SPI  Process 
D  First  Improvement  Steps  need  to  be  practical 

°  “Plan,  Do,  Check,  Act"  Cycles  are  essential 
□  Every  Organisation  is  different,  for  example: 

-  Nationality 

-  Position  at  the  learning  Curve 

-  Flexibility 

o  Assessment  is  relatively  easy 

Q  Deployment  of  the  new  Processes  is  the  most  difficult  Part 


PHILIPS 


SPI  Support  Experiences 

o  SPI  is  dealing  with  Management  of  Change 
°  Roadblocks  that  are  often  encountered  in  Philips; 
o  Lack  of  Management  Awareness/  Direction 
o  Culture  of  an  Organisation  (Hardware  Oriented) 
o  Competition  of  real  Projects 
o  Lack  of  Change  Management  Skills 
o  Lack  of  Involvement  of  non-technical  Roles 
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SPI  Results 


a  Senior  Management  Awareness  has  grown 
a  Most  Software  Groups  have  running  SPI  Programs 
D  Process  Maturity  and  Software  Knowledgability  grow 
Q  Metrics  are  essential  to  demonstrate  Improvement 
a  Collective  learning  Mechanisms  work  well 

i 

I 
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Ap|>ru4cheb  to  Improvement  Support 


European  SEPG  ‘97 
Identified  Challenges 


▼  Creating  a  process  improvement  organisation  that  works  . 

▼  Obtaining  and  keeping  both  senior  management  and  organisational 
support 

▼  Obtaining  qualified  people  for  doing  process  improvement 
T  (Creating  action  plans  and  maintaining  these) 

▼  Once  working  groups  (we  call  these  task  forces)  are  established, 

assure  that  they  do  something  sensible . 


Alcuef  TcMcom  Norway  AS 


fatt/amsiarda  si^lS  06  97 


3A 


European  SEPG  ‘97 
Process  Improvement  Organisation 


▼  Senior  management 
has  a  specified  respon¬ 
sibility 

'  Prioritising  improv 
'  Go/no  go.  tracking 
•  Sponsoring  task  forces 


▼  SEPG  (as  we  have 
defined  it)  is  responsible 
for: 

*  Establishing  and  run¬ 
ning  a  metrics  program 


9MW  inMMCeerM 


•  Identifying  potential  improvements  through  metrics,  assessments  and  def  prev. 


•  Define  and  present  the  improvement  for  SMRB 


Alcaict  Tetecom  Norway  AS 
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Appr<Mches  to  Proces!»  ImprovemenI  Support 


European  SEPG  ‘97 

_ Process  Improvement  Organisation 

▼  Process  Improvement  (PI)  is  responsible  for  investigating  the 
improvements  through  task  forces; 

•  What  &  how  to  improve 

•  Conducting  the  experiment 

•  Establishing  new  procedures  and  a  training  program 

•  The  Process  Control  Board  is  an  "impartiar  group  who  will  evaluate  the  output 
from  the  task  force 

▼  Resource  development  (RU)  is  the  organisations  responsible  for  methods 
&  technology  and  they  are  therefore  the  customers  of  the  project  PI  RU 
are  responsible  for  implementation  and  tracking  of  implemented 
improvements 


AKalei  TeMcwn  Noway  AS 
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European  SEPG  ‘97 
Obtaining  Support 


Senior  Management  (SMRB)  support  is  obtained  through; 

■  Establishing  cost/benefit  analysis  pr.  improvement 

•  SMRB  prioritising  improvements  (which  to  run,  which  to  delay,  ...) 

•  SMRB  sponsoring  each  task  force  (one  from  SMRB  per  TF)  -  special 


responsibility  vs  tracking,  helping  etc.  the  TF 
Regular  progress  report  meetings 


▼  Organisational  support  Is  obtained  through; 

•  Participation  in  assessment  ® 

•  Meeting  with  everybody  (every  6  months)  in  small  groups  to  discuss  the 
organisations  needs,  prioritations,  plans  for  improvement  etc. 

•  Releasing  x-news  bi-monthly,  giving  updates  on  progress,  future  plans, 

prioritations . 

•  Having  as  many  as  possible  participate  in  PI  —  TF’s,  reference  groups,  PCB 


Airatei  Tetecom  Norway  AS 
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European  SEPG  ‘97 
Obtaining  Qualified  People 

▼  Identifying  smaller  improvements  which  can  be  done  in  -6  months  in  a 
project  with  3-4  people  20-50% 

•  It  is  possible  to  release  'good'  people  from  “important*  projects  <50%  for  <6 
months. ... 


T 


Alcatel  Telecam  Horway  AS 
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European  SEPG  ‘97 
Working  Groups 


We  call  our  working  groups  task  forces,  and  we  try  to  obtain  good 
progress  by; 

•  Running  kick-offs  (focus  on  establishing  a  common  set  of  goals.  CMM. 
detailed  planning  next  2  months) 

•  Doing  a  workshop  on  the  topic  in  question  (e  g.  requirements  management) 

•  Having  bi-weekly  progress  report  meetings 

•  Arranging  monthly/bi-monthly  meetings  with  a  reference  group  for  advice, 
discussions  etc. 

•  Arranging  1  till  2  meetings  with  senior  management  for  advice,  discussions 
etc. 

•  Employing  external  consultants,  specialising  in  the  topic  in  question,  to  help  in 
addressing  the  right  questions,  going  through  the  right  process,  obtaining  an 
overview  sooner,  etc. 


Atcaw  Telecom  Nofwey  AS 
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European  SEPG  ‘97 
What  We  Should  Improve 


T  Support  for  the  project  manager  of  PI  to; 

•  Improve  the  current  process  (running  TF's.  obtaining  support,  ‘seeing  other 
ways  of  doing  things’,  etc.) 

•  Have  somebody  to  discuss  issues  with 

•  Employing  a  “devils  attorney’ 

▼  Arrange  mini-assessments  and  relate  findings  to  current  business 
status/goals  -  re-establish/strengthen  senior  management 
support/commitment 


AkuM  Ttteoom  NoiHay  AS 
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Practical  Implementation  of  Process 
Improvement 


Keith  Jackson 
TBL 

Mead  House 
Heathfield  Lane 
Chislehurst 
Kent  BR7  6AH 


Tel:  +44  (0)181  295  0234 
Fax:  +44  (0)181  467  7843 
Email:  Keith  Jackson2®compuserve.com 
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Objectives 

To  provide  guidance  and  support  to  an 
organisation  that  has  completed  an  assessment 
and  needs  to  deploy  improvement  activities. 

To  provide  do’s  and  don’ts  on  how  to 
successfully  establish  and  deliver  an 
improvement  programme. 

To  discuss  lessons  learned  from  software 
process  improvement  experiences. 
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Contents 

•  Why  bother? 

•  Why  do  most  Process  Improvement 
initiatives  fail? 

•  A  common  dilenuna 

•  5  Common  success  features 

•  6  Principles  of  Process  Improvement 

•  How  do  we  do  it  -  in  practical  terms? 

•  How  do  we  manage  change? 

•  How  do  we  reduce  risk? 
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Why  bother? 


•  80%  of  Process  Improvement  initiatives  fail 
(Based  on  SEI  data  1996) 
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When  applied  properly.  Process 
Improvement  delivers: 

•  Measurable  improvements  in  time  to  market, 
predictability,  productivity  and  delivered 
quality 

•  Survival  (which  is  of  course  not  compulsory!) 

•  Improvement  of  bottom  line  performance 
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Organisations  Have  a  Common 
Dilemma 

How  do  we  move  to  a  level  2  or  level  3 
maturity  level  when  we  are  a  level  1 
organisation? 

Because  we  don’t  have  a  level  2  or  level  3 
infrastructure  and  level  2Aevel  3  KPA 
experience  it  will  take  us  an  average  of  3-5 
years  to  move  from  level  1  to  level  2  and  2 
years  from  level  2  to  level  3. 

Using  external  help,  we  can  move  from  level 
1  to  level  2  with  lower  risks  and  lower  costs 
in  2  years  -  sometimes  quicker 
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PANEL: 

Approaches  to  Process  Improvement  Support 


Successful  SPI  Initiatives  Have  Five 
Common  Features 

1)  Executive  management  commitment  and 
direction. 

2)  Management  of  change  -  Culture  and 
communication. 

3)  Proven  SPI  model. 

4)  Education  and  training. 

5)  Measurement  and  metrics. 
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Six  Principles  of  Process 
Improvement 

1)  Improvement  direction  must  start  at  the  top 

2)  Everyone  must  be  involved  in  the  improvement 
process 

3)  Effective  improvement  requires  knowledge  of 
current  process 

4)  Improvement  is  continuous 

5)  Improvement  requires  investment 

6)  Use  external  help  to  reduce  risks  and  shorten 
timescales 

Umi  CopyiigM  ICI  1 997  TOK  B  Lid  All  Rights  RaMrvwl  R«f:  KJ  SEPG  97  10 
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How,  in  practical  terms? 

1  Customer  focus 

“Any  Process  Improvement  initiative  exists  to 
serve  the  business  needs  of  the  organisation.  It 
is  not  the  other  way  around.” 

2  A  project  based  approach 
initiate 

diagnose 

establish 

action 

learn 
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The  IDEAL  Model 


Initiating 


Diagnosing 
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I  Learning  •* - j^^Acting^J* 
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Approaches  to  Process  Improvement  Support 


How,  in  practical  terms? 

3  Delivering  results 

•  clear  phases 

•  fixed  deliverables 

•  management  buy-in  and  sign-off 

•  quick  wins 

•  measurable  results 
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How,  in  practical  terms? 

4  Recognise  difficulties  of  change 

•  think  strategically 

•  plan  tactically 

•  deliver  operational  processes 

5  Recognise  that  we  do  not  all  start  from  the 
same  point 

•  tell 

•  sell 

•  involve 

•  delegate _ 
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Apprajchc*  to  ProccK  bnprovcfncnl  Support 


have  to  manage  change 

External  Change  Initiative 


Deny  Problem 

Commitment 

j  (Wli|0.  us?) 

(I  know  it  works)  ^ 

Resist  Change 

2  (Yes,  but) 

Pilot 

(OK  -  Prove  it!)  ^ 

Internal  Mt 

irent  View 
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We  have  to  reduce  risk  of  failure 


HI 


Spend 


Commitment 

Confusion 

High  return 

t  ttt 

No  go 

focused  projects  ^ 

4 

Comfort 

Caution 

Acknowledgment 
that  Process 

Scoping 

Improvement 
works  and  can  be 

~  planning 

quick-result  pilot 

profitably  applied  in 

Low  spend 

many  areas  2 

1 

LO 


Risk  of  failure 


HI 
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Approaches  to  Process  Improveinent  Support 


Cost  of  Implementation  Failure 

Each  time  an  improvement  effort  fails  to  achieve  its  stated 
objectives,  it  incurs  both  short-term  and  long-term  costs 


Direct 


Short  Term 


Long  Term 


Wasted  resources;  Business  strategies 

•  Money  not  accomplished 

•Time 

•  People 

Business  goal  not  achieved 

•Morale  suffers  *  Lower  confidence  in 

leadership 

•  Joh  security  threatened  *  Resistance  to  change 

increased 

•  Next  change  more  likely 
to  fail 


Indirect 
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Lessons  Learned  from  Success  and 
Failure 

Business  Process 

•  Product  and  service  definition 

•  Different  assessment  vehicles  give  different 
returns 

Measurement  and  Control 

•  Simple  metrics  programme  deHnitions 

Human  Resources 

•  Review  your  training  needs  early 

•  Recognise  the  value  of  SPI  training 
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Approaches  to  Process  Improvement  Support 


Lessons  Learned  from  Success  and 
Failure  (cont) 

Management  of  Change 

•  Business  mission  and  goal  definition 

•  Market  scoping 

•  Strategic/Tactical  Planning 

Management  Commitment 

•  Conferences  such  as  SEPG  can  provide 
significant  impetus 

•  Use  workshops  to  involve  management 
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Approachn  to  Process  Improvement  Support 


•  ISPI  Background 

•  Process  Improvement  Infrastructure 

•  Up  Front  Expectation  Setting 

•  Business  Objectives 

•  Guidance  for  Action  Planning 

•  Incremental  Approach 

•  Process  Mentors 

•  Training,  Action  Planning,  Incremental  Approach, 
with  Process  Mentors  Package 


Institute  for  Software  Process  Improvement  Inc.  (ISPI) 

•  Founded  in  1991  by  Tim  Kasse  and  Jeff  Perdue 

•  Incorporated  in  1996 

Spin-off  of  the  Software  Engineering  Institute's  Process 
Program 

ISPI  is  an  international,  full  service,  process 
improvement  consulting  company,  assisting 
organizations  in  implementing  process  improvements 
ir  Business  Objei 


that  support  their  I 


bjectives 
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ISPI  Background  -  2 


ISPI’s  process  improvement  consulting  services  include: 

•  Process  improvement  implementation  support 

•  Action  planning  guidance  and  support 

•  Process  improvement  related  training 

•  Assessments  and  Evaluations 

•  Process  improvement  awareness  and  expectation 
setting 


Sample  Improvement  Infrastructure 


V^aenlor  Manag«nienr''SJ’. 
Advisory  Board  > 

'  (  Stealing  Committee  J  /  ) 


Senior  Management 


Middle  Management 


Project  Management 


Project  Members 
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Process  Improvement  Model 

(Up  Front  Expectation  Setting) 


Appraisal  of  the 
Software 


r  L 

Process 

1  .  ... 

71 

/ 

7 

/ 

Commitment  to 
Software  Proceae 
Imj^veiheni 

) 

SKtfl^re  Process 
Improvement  " 

3 

1/ 

/ 

irnplementation^f> 
Software  Process 
Improvements 


B 

Business  Objectives  || 

A  continuous  process  improvement  initiative  is  one  that 
encourages  and  supports  change 

It  includes 

•  Setting  expectations 

•  Training 

•  Conducting  assessments 

•  Action  planning 

•  Implementing  the  process  improvement  processes  and 
procedures 

First  and  foremost  it  supports  an  organization’s  Business 
Objectives 
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Approaches  to  Process  Improvement  Support 


The  goal  of  the  GAP  is  to  prepare  the  foundation  for  an 
Action  Plan  by  framing  the  process  improvement 
program  in  terms  of  the  assessment  or  evaluation 
results 


Benefits  of  the  GAP 


The  GAP  provides  management  with  the  ‘big  picture’ 

•  What  needs  to  be  done 

•  Who  needs  to  be  involved 

•  What  it  might  take  to  accomplish  true  and  lasting 
improvements 

The  GAP  is  the  basis  for  management  decision-making 

•  Determining  priorities  in  light  of  corporate  vision  and  current 
business  environment 

•  Establishing  visible  commitment  for  the  program 
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Benefits  of  the  GAP?  -  2 


The  GAP  identifies  process  improvement  roles  and 
responsibilities  for  all  levels  of  management  and  staff 

The  GAP  provides  important  information  for  everyone 
involved  in  the  development  of  the  action  plan 

•  Major  initial  steps  in  developing  the  Focus  Area,  sections  of 
the  overall  Action  Plan 

•  Input  into  the  context  area  of  the  Action  Plan-the  section 
that  is  generic  to  all  of  the  Focus  Areas 

•  Planning  considerations  when  implementing  fundamental 
change 


Divide  the  process  improvement  activities  into  incremental 
phases  that  deliver  improved  practices  every  3-4  months. 

Each  phase  is  composed  of: 

•  Preparation 

•  Pilot 

-  implementing  the  practices  on  a  pilot  project 

-  evaluating  and  refining  the  practices  if  necessary 

-  refining  the  overall  plan  if  necessary 

•  Diffuse  practices  to  other  appropriate  projects  until  it  is 
institutionalized  throughout  the  organization 
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Approaches  to  Proress  Improvement  Support 


II 

Incremental  Approach  -  2  I 


Each  phase  is  designed  to  deliver  one  or  more  specific 
improvement  activities  or  practices.  These  practices 

•  Are  managerial,  organizational,  technical,  or  mechanical 

•  Must  be  introduced  in  functionally  coherent  sets 

•  Must  be  linked  to  the  business  objectives  and  priorities  of 
the  business  unit 

•  Must  be  appropriately  trained  with  coaching  available 
during  initial  implementations 

•  Must  be  practical,  proved,  and  adaptable  to  the  business 
unit's  needs 


“11 

Process  Mentoring  I 


Process  Mentors  are  experts  in  a  Focus  Area  (e.g.,  Project 
Management)  with  a  proven  track  record 

Provide  guidelines  and  constraints  for  the  Working  Groups  or 
Process  Action  Teams  to  work  within 

Provide  action  planning  and  implementation  guidance  to 
focus  area  Working  Group  with  possible  support  from  In- 
house  experts 

•  Expert  mode 

•  Sharing  mode 

•  Supporting  mode 
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Approaches  to  Process  Improvement  Support  j 


Process  Mentoring 


Provide  samples,  checklists,  and  starter  kits  from  asset 
library  and  experience 

Coach  project  leaders  and  practitioners  In  the  use  and 
adaptation  of  these  assets 

Monitor  progress  and  provide  continuous  feedback  (to 
projects  and  Process  Action  Teams) 


Technology  transfer  should  always  be  the  Process 
Mentors’  objective 


Training,  Action  Planning,  Incremental 
Approach,  Process  Mentor  Package 


Training  is  provided  to  the  Process  Action  Team  to 
provide  necessary  background  in  a  focus  area  and  a 
framework  for  the  subsequent  action  planning 

Process  Mentors  are  either  the  ones  who  present  the 
training  or  are  in  attendance  when  the  training  is 
presented 

Process  Mentors  work  with  the  Process  Action  Team  to 
develop  Guidance  for  Action  Plan  detail  for  the  Focus 
Areas 
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Training,  Action  Planning,  Incremental 
Approach,  Process  Mentor  Package  -  2 


Process  Mentors  work  with  the  Process  Action  Teams  to 
refine  the  Implementation  Tasks  into  implementable 
increments 

Process  Mentors  work  with  the  Process  Action  Teams  to 
support  projects  for  2-3  increments 

Progress  is  checked  and  the  need  for  further  Process 
Mentor  involvement  is  determined 


Summary 


Process  Improvement  Initiatives  can  be  enhanced  and 
accelerated  through 

•  Establishing  a  SPI  Infrastructure 

•  Taking  more  time  to  properly  set  expectations  up  front 

•  Tying  the  process  improvement  actions  to  the  business 
objectives 

•  Providing  a  bridge  between  assessment  or  evaluation  results 
and  the  Action  Planning  and  Implementation 

-  Help  management  to  prioritize  process  improvement  focus 

-  Provide  a  starter  kit  for  the  Process  Action  Teams 
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Summary  -  2 


•  Implementing  the  process  improvements  using  an 
incremental  approach 

•  Using  Process  Mentors  to  coach  and  guide 

•  Combining  training,  action  planning,  and  the  incrementai 
approach,  with  process  mentors 


ISPI 


15  N.  Collinwood  Drive  Klein  Heiken,  101 

Pittsburgh  PA  15215  (USA)  B.2950  Kapellen  (Belgique) 

Tel.  00  1  412  781  1701  Tel.  00  32  3  605  4875 

Fax.  00  1  412  781  0805  Fax.  00  32  3  605  4876 
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Agenda 


•  introduction  and  Background 

•  SPICE  Trials  Organisation 

•  Phase  2  Trials  Objectives  and  Status 

•  Market  Transition 

•  Report  from  Working  Group  10 

•  Conclusion 
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What  is  SPICE? 

•  Development  of  an  International  Standard  on 
Software  Process  Assessment 

•  The  SPICE  project  created  to: 

•  ensura  envelopment  route 

•  solicit  opinions  and  Input  of  world  experts 
’  carry  out  early  trials 

•  provide  early  feedback 

•  create  awareness  of  the  new  standard 

«  SPICE  *  Software  Process  Improvement  and 
Capability  dEtermination 
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SPICE  -  the  reference  model 

*  Two-dimensional  model  for 
processes  and  process  capability 

•  Capability  Levels 

•  Process  Attributes 

«  Process  Categories 

•  Processes 


CL5 

CL4 

CL3 

CL2 

CL1 

CLO 


P1  P2  P3 . Pn 
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Trials  Organisation _ 

SPICE  Proi«ct  Manager 
AlaeOofSngIVFCSE 


IntamaUanal 
Triala  Coordlnalor 
Bob  Smith 


1 


USARTC 

SB 

Canada  RTC 

ASEC 

Eurepa  RTC 
ESI 

! 

S  Asia  PacHIc  RTC 

SOI 

Noftham  PacHIc  RTC 
SOKAIMIV 

^ - 

! 

[  1  i 

1 

Local  Triala 
Coordinator 
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Phase  2  Objectives 
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*  Adequacy  of 

•  Reference  Model 

•  Requirements  for  Conducting  an  Assessment 


•  Usefulness  of  guidelines  for 

•  Process  Improvement 

•  Capability  Determination 

•  Assessor  Qualification  and  Training 

•  Conducting  a  Software  Process  Assessment 
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Trials  Questions 

•  Does  the  Reference  Model  provide 

•  a  correct  and  well-defined  set  of  processes 

•  a  well-constructed  system  of  process  capability 

•  a  usable  rating  scale 

•  a  means  for  assessment  model  compatibility 

•  Does  the  Assessment  Model  provide:* 

•  a  good  mapping  to  tfw  Reference  Model 

•  a  well-defined  set  of  process  indicators 

•  a  well-defined  set  of  process  management  indicators 

•  Are  the  Requirements  for  Assessment  :- 

•  well-defined  and  understandable 


£S£PG  199? Arnmfmn  ceSt199T  SC1 1997 


Crmegre  MMen  unwerMT 

^  Soflwwe  Engineefinfi 

More  Trials  Questions 

•  Who  has  used  SPICE  and  what  do  they  think  ? 

<  What  is  the  cost  of  performing  an  assessment  ? 

<  How  does  process  maturity  relate  to  project 
performance  ? 

*  Does  assessment  aid  process  improvement  ? 
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Can  Results  be  Compared  ? 
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CMM 


^  5  Optimizingl 
4  Managed 


3  Defined! 


2  Repeatabl* 


1  Initial 
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SPICE  PROCESS  PROFILE 
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Trials  Status 
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REGION 

REGISTERED 

COMPLETED 

DATA 

RETURNED 

Europe 

72 

18 

2 

USA 

8 

0 

0 

Canada 

8 

0 

0 

Central  &  South  America 

Southem-Asia-Pacific 

42 

25 

6 

Northen-Asia-Pacific 

15 

0 

0 

Totals 

145 

43 

8 
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Who  Can  Participate 

*  Organisations 

•  Assessors 

>  Model  Providers 

•  Method  Providers 

*  Assessment  Tool  Providers 

« 


« 


« 


fl 


i 


Wednesday  18  June 


(C308b)  S-9 


Wednesday  18  June 


(C308b)  $-10 


Wednesday  Itf  June 


(C308a)  S-7 


ESj _ 

PDTR  Review 
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ISO/IEC  15504  is  a  preliminary  draft  technical  report 
(PDTR)  in  the  area  of  software  process  assessment. 

The  first  PDTR  was  released  by  ISO  in  November, 
1996  for  a  3  month  ballot  ending  February  27,1997. 

A  meeting  of  ISO/IEC  JTC1/SC7/WG10  was  held  in 
Singapore  on  April  7-11, 1997  to  dispose  of  the  ballot 
comments  on  the  PDTR. 
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Ceme^e  Meier  Unweney 

Software  Engineering  Institute 


•  normative 
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Requirements  for 
Conducting  an  Assessment 
Part  3 
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Voting  on  the  9  documents 

The  voting  for  each  of  the  parts,  including  late  votes, 
was  as  follows*: 


Part  1  17-3 
Part  2  14-6 
Part  3  14-6 
Part  4  15-5 
Part  5  13-7 


Part  6  16-4 
Part  7  17-3 
Part  8  17-3 
Part  9  17-3 


*-includes  1  vote  after  comment  report 
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— 
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Soflwars  Enginssilng  Institute 

Key  Issues  Identified  in  Ballot  Comments 

Relationship  to  ISO/IEC  12207  is  weak. 

Level  4  and  5  attributes  are  not  clearly  articulated. 

Process  attribute  scale  does  not  provide  a  suitable 
basis  for  repeatable  assessments. 

Compliance  requirements  are  not  clear. 

Overall  size  of  the  document  set  is  too  large. 

Certification/registration  intent  of  15504  is  not  clear. 
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Key  Agreements  at  Singapore  meeting 

ISO/IEC  12207  was  fully  embraced  as  the  defining 
document  for  software  processes. 

Clause  was  added  in  documents  that  makes  clear  that 
15504  is  not  intended  for  certification. 

The  project  agreed  in  principle  to  a  broader 
interpretation  of  the  process  instance  concept 

Part  3  will  now  contain  requirements  for  an 
assessment  method. 


eSEPG  rnTAmsifdam  CESI1997  $£11997 


i 


i 


t 


4 


4 


MHaw 

Software  Engineering  Irtebtute 

Other  Issues 

A  proposal  was  made  to  restructure  the  document  set 
Size  of  the  document  set  was  dismissed  as  a  non-issue. 
Phase  2  trials  were  extended. 

US  proposal  to  limit  part  5  to  a  single  example  was  deferred. 

A  proposal  was  made  to  separate  part  5  from  the  rest  of  the 
document  set 
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Areas  of  Continuing  Concern 


The  role  of  part  5  (exemplar  model)  in  the  product  set  is  a 
contentious  issue. 

Certification/registration  of  methods,  models,  and 
assessors  is  desired  by  some. 

Ballot  progression  is  unclear. 


1997 Anattt^  Sf/ f997 


ESI _ 

PDTR  ballot  conclusions 


Cernepe  Helen  UrM«rsey 

Software  Engineering  Institute 


Singapore  meeting  resulted  in  some  key  breakthroughs 
which  bode  well  for  the  CMM  community  as  well  as  the 
global  software  engineering  community  and  for 
widespread  acceptance  of  the  emerging  standard. 


However,  agreements  must  be  fully  implemented  in  the 
product  set  and  then  subjected  to  the  normal  balloting 
process  for  full  confirmation  and  acceptance. 
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For  further  information 


SoAom  Enoinnring  hwMul* 


Bob  Smith,  European  Software  Institute,  Spain 
Bob.Smith@esi.a8 

Steve  Masters,  Software  Engineering  Institute,  USA 
8mm@sei.cmu.edu 

•  Alec  Doriing,  IVF,  Sweden 

adg@ivf.se 

*  Terry  Rout,  Software  Quality  Institute,  Australia 

T.Rout@cit.gu.edu.au 

Luciano  Guerrero,  Applied  Software  Engineering  Center,  Canada 
lguerrer@crim.ca 
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Assessment  and  Optimization  of  System  Architectures 
Experiences  with  Industrial  Applications  at  Siemens 


Dr.  tWeh««l  GIOQ«f.  Dr.  Sttftn  Jockutch,  Noitcrt  Water 
Slamatia  AG 
Tachnology  Group 
Municft 


^  SAA  -  System  Architecture  Analysis 


The  Role  of  Architectures  for  SW-Development 


e  a  good  architecture  is  an  essential  precondition  for  market  success 

J  major  characteristics  of  a  system  are  delennined  by  its  architecture 
»  efficiency,  changeability,  reliability. ... 

e  principle  design  decisions  are  marie  in  various  engineering 
scenarios,  e.g. 

j  in  the  early  phases  of  development  projects,  balancing  market  needs  and 
technical  possibilities 

□  for  harmonizing  architectures  of  different  products  in  order  to  re-use  common 
components 

□  to  adopt  a  system  architecture  to  distributed  development 

•  today  architscture  defintion  and  evolution  is  an  ad  hoc  process 

□  no  systematic  analysis  of  alternative  solutions 

a  no  regular  assessment  and  optimization  of  architectures 
no  active  and  controlled  evolution  of  architectures 
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System  Architecture  Analysis  (SAA) 
Goals 


ZTSWJ 


•  Supply  method  for  analyzing  and  optimizing  architectures 
j  Verify  design  decisions 
□  Identify  optimization  potential 


e  Objective  deciaiona 

j  Structure  decision  space 
j  Direct  comparison  of  competing  design  decision 


a  Effective  communication 

□  Describe  architecture  without  usage  of  special  notation 

□  Concise  description  of  pros  and  cons  of  competing  solutions 


^  SAA  -  System  Architecture  Analysis 
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Characteristics  of  SAA 

e  Considers  all  relevant  perspectives: 

□  Technological/engineering  view 

□  Customer  and  market  demands 

j  Organization  requirements  (Time,  Costs, ...) 
j  Quality  criteria 

e  Indicates  to  which  degree  an  architechire  fulfills  the  criteria 

e  Identifies  possible  optimizations 

□  based  on  evaluation  of  alternative  solutions 

□  with  consideration  of  resulting  benefit 

e  Involves  experts  from  Development,  Marketing,  Sales,  Service 
J  to  guarantee  acceptance  and  internal  communication  of  results 
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Example:  Assessment  of  Architecture  Framework 
for  Multimedia  Communication  System 


Situation 

•  Dynamic  and  rapidly  expanding 
telecommunication  industry 

•  New  competitors 

.  Very  early  development  stage 

.  Framework  developed  by  cross¬ 
functional.  geographically  distributed 
team 


Re<|uireinants 

.  Flexibility  and  scalability  w/r  to 
capacity  and  features 
.  Integration  of  existing  PBX 
.  Supply  open  standardized  interfaces 
.  Cooperate  with  LAN/PC  world 


Goals  of  Assessment 

Is  the  concept  suited  to  meet  ail  these  requirements'’ 

What  are  the  possible  optimizabons.  open  issues  and  risks? 


^  SAA  -  System  Architecture  Analysis 
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System  Arohitecture  Analysis  (SAA)  1 

Overview 

Evaluation  Criteria 
•  based  on  all  requtrements 


Architacture 

■  Investigation  focuses  on  system  aspects  and 
realization  concepts  for  these  system  aspects 
■»  How  well  is  each  realization  concept  suited  to  fulfill 
each  of  the  requirements? 

■»  How  well  do  the  concepts  fit? 


Customer 
Requiramenti 


Organization 

Requiramsnts 

(Time.  Costs. 


Application 

indepcnrlant 

requirements 


> 

> 


Systsm  Aspect 
Structure 


^  System  Aspect  ^ 
Dsta  Storage 


The  sneezed  V,Civxre  _ 
Architecture _ ^ 


System  Aspect 
\Communlcallaiw 
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System  Arohitecture  Analysis  (SAA) 
Procedure 

^  SAA  •  System  Arctiitecture  Analysis 


Step  1:  Structure  and  priorize  requirements 


Procedure 

•  2  to  3  workshops  with  experts  from 
marketing,  sales,  service,  and 
development 

•  Identification,  hierarchical  organization 
and  prioritization  of  requirements 


ResuKs 

Hierarchy  of  requirements  from 
organization,  market,  customers  and 
development 

One  hierarchy  level  becomes  set  of 
evaluation  criteria  (about  30) 
Weights  (or  criteria 


^  SAA  -  System  Architecture  Analysis 
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Step  2:  Identify  system  aspects  and  realization  concepts 


Procedure 

■  2  to  4  workshops  with  developers  and 
system  architects 

•  Build  description  of  architecture  in  terms 
of  underlying  design  decisions  and 
chosen  realization  concept 

•  Find  alternative  realization  concepts  for 
each  system  aspect 


Results 

Set  of  about  20  basic  system  aspects 
(design  dimensions) 

2  to  5  alternative  realizations  for  each 
^  Common  understanding  of  each 
system  aspect  and  realization 


Design  space  supports  abstract  and  concise  view  of  architactura  concepts 
Many  design  decisions  are  “unconscious":  no  documentation,  but  accepted  by 
all  involved  experts 

>  Design  space  concept  inspires  formulation  of  completely  new  solutions 
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Step  3;  Evaluation  | 

Procedure 

■  2  workshops  with  developers,  system 
architects,  and  experts  from  marketing, 
sales  and  service 

•  Detailed  evaluation  of  two  aspects 

-  How  well  is  each  realization  concept 
suited  to  fulfill  each  requirement? 

-  How  well  do  realization  concepts  fit? 

Results 

o  Evaluation  of  each  realization  with 
respect  to  each  criterion  and  of  each 
realization  with  each  other 

>  "Localized  evaluation"  (one  concept,  one  criterion)  supports  efficient 
evaluation  procedure 

>  Tradeoffs  became  transparent  and  conscious 

>  Discovery  of  interactions  and  implications  which  were  overseen 

^  SAA  -  System  Architecture  Analysis 
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Step  4:  Optimization 

StrangthAMakiMU  proflto 


'  To  whcti  degree  does  the 
architecture  meet  the 
requirements? 

'  Which  requirements  are 
being  supported  only 
badly? 


Evaluation  of  deeign  dacalooa 


jraeauVBi 

'  r-* 

•r  How  have  the  realization 
concepts  been  evaluated 
regarding  special  criteria? 
Which  realization  concepts 
have  to  be  improved? 


Opiimizatton  measures 


'  How  can  the  architecture  be 
improved? 

'  What  does  the  strengthAweakness 
prohle  of  the  improved  architecture 
took  like? 


^  SAA  •  System  Architecture  Analysis 
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Assesement  of  MM  system  architecture:  1 

Results 

Evaluation  of  the  architecture 

Optimizations 

O  Precise  judgement  on  suitability  of 
the  architecture  for  fulfilling  the 
requirements  based  on  strength- 
weakness  profile 

O  Improved  software  layering 
structure  in  order  to  optimize  both 
performance  and  encapsulation 
of  low  level  functions 

O  Identification  of  "design  tradeoffs" 
Example: 

•  Conflict  "standards  vs.  distinctive 
features" 

O  Identification  of  open  or  unspecified 
design  decisions 

Further  benefits 

O  Representation  supplies 

transparency  to  experts  and  is 
suited  for  communication  to 
management 

^  SAA  •  System  Architecture  Analysis 
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Application  within  different  scenarios,  Example  1 
Harmonization  of  Architectures 


Situation 

•  Several  systems  of  an  application 
domain  have  been  developed 
independently 

*  Similar  components  are  developed  and 
maintained  several  times 

«  Re-use  of  components  is  hindered  no 
standardized  interfaces,  different 
software  plattforms 


Goal 

•  Reduce  development  time  and  effort  by 
re-using  common  components 

•  Standardize  platfomn.  archkecture  and 
interfaces 

•  Homogenous  user  interface 

•  Transparent  basis  for  decision  making; 
demonstrate  benefits 


Challenge:  Effort  spent  for  architecture  harmonization 
must  be  balanced  to  expected  benefits 

Common  architecture  must  be  suitable  to  meet  future  requirements 

Architecture  must  be  able  to  incorporate  new  and  upcoming 
technologies 
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Harmonization  of  Architectures 
Extending  the  SAA  procedure 


Inventory  of  actual  aystame  | 
andttMirarchRacturaa  | 


Mapping  to  SAA  atapt  | 

Slap  1:  RaquirwiMmts 
and  avaluatfon  crftaria 

□ 

Stap  2: 

Idanttfy  raallzatton 
coffca^ 

IZ3 

Stap  3  4  4:  Evaluailon 

4  OpUmizitton 

Invaatlgatlon  of  banafWa  and  dafInWonofgoala  | 


raqultenianti 


' 'future  diiniist '  "a 
eeanarioiMnd  I 
product  roedmape  j 

'L 


Analyalaof 

upcoming 

^achnotogja^ 


3 


Migration  and  introduction  procadura  I 
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Application  within  different  scenarios.  Example  2 
Adapting  architecture  and  process  to  distributed  development 


Goal;  globally  distributed  software  development 

•  Several  distributed  development  sites:  short  cycle  time  for  customer 
segment  specific  features 

^  e  One  development  site  responsible  for  common  components  and  platform 
^  SAA  -  System  Architecture  Analysis 


Adapting  architecture  and  process  to  distributed  development 


Variant 

Process 


Variant  1  V.1 

4  7~~4 


Variant  1  V.2 

4  4  4 


Platform 

Process 


Platform  VI 


Platform  V  2 


Solution 

•  Restructuring  of  the  development  process 

Is  Splitting  the  platform  process  from  variant  process 

r)}  Synchronizatiorr  points  for  stabilizing  the  overall  architecture  using  SAA 

•  Restructuring  of  the  architecture 

Is  Definition  of .  jmmon  components 
Interface  to  variant  parts 
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Ongoing  Research 

•  Organization  and  procedures  for  development  of  architectures 


•  Procedural  model  for  architecture  definition 

□  Architecture  platforms  for  families  of  products  for  an 
application  domain 

□  Common  component  definition  based  on  reference 
architectures 

•  Documentation  of  architectures 

□  focused  on  supporting  communication  between  different 
functional  areas 

•  Metrics  for  Architectures 
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Summary  and  next  steps 


e  SAA  is  suited  for  a  variety  of  application  domains 

□  Medical  Systems.  Automation.  Communication 

•  SAA  can  be  adapted  to  different  engineering  scenarios 

□  Architecture  definition,  restructuring  projects,  architecture  harmonization 

e  SAA  improves  communication  between  involved  functions 

□  Communication  and  negotiation  between  functional  areas  (Maiireting. 
Sales.  Service) 

□  Compact  documentation  of  design  decisions 

□  Objective  decision  making 

•  Satisfactory  results  achieved  with  qualitative  judgements 

a  SAA  well  suited  for  early  phases  of  architecture  definition 

•  Future  focus:  procedures  and  organizational  implications  for  architectural 
design 


^  SAA  -  System  Architecture  Analysis 
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Understanding  and 
Improving  Your  Suppliers 


'»7.SATn 


Chris  Amos  and  Mick  Bennett 

Software  Supplier  Assessment  Team 


Summary 


The  practical  adaptation  and 
enhancement  by  BTs  Software 
Suppher  Assessment  Team  of 
existing  methods  and  models  for 
understanding  and  improving  our 
SuppUers. 
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Why  BT  Need  To  Assess  Suppliers 


•  We  are  totally  dependent  upon 
software  for  our  commercial  survival 

•  We  have  some  of  the  world’s  biggest 
programmes. 


The  Track  Record  Is  Not  Good 


•  80%  of  projects  are  delivered  late  and 
over  budget 

•  40%  of  systems  fail  or  are  abandoned 

•  only  10-20%  of  systems  meet  all  of 
their  success  criteria 

•  failures  are  rarely  purely  technical  in 
origin 


The  pcrfoniuuiGC  of  Infonnesion  Technok>gy  ind  the  n>k  of  human  and  arganizational  fadora. 
InatititcofWorii  Piychoiogy.  Sheffield  Univenity  -  Juuary  1996 
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The  Track  Record  Is  Not  Good 


•  51%  do  not  use  effective  project 
management 

•  77%  do  not  have  a  tried  and  tested 
method  of  estimation 

•  63%  do  not  adhere  to  any  recognised 
quality  standards 


BT 


Supplier  Assessment  In  BT 


•  We  use  two  different  methods  at 
present: 

•  The  Healthcheck  for  internal 
suppliers  only  and 

•  Software  Supplier  Assessment 
(SSA)  for  internal  and  external 
suppliers 

•  Less  formal  ‘project  firefighting’ 
reviews  and  assessments 
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SVC  Jm*T- SATA 


WhaVs  in  it  for  BT? 

•  A  better  understanding  of  BT’s 
Supplier  base 

•  More  manageable  risks  to  BT  through 
better  project  preparation 

•  Less  ‘troubleshooting’ 

•  Tender  adjudication  speeded 

•  More  objective  Supplier  selection 

•  More  appropriate  contracts 

•  ‘BT  lessons’  fed  back  for  internal 
improvement 


< 


4 
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WhaVs  in  it  for  our  Suppliers? 


•  ‘Free’  consultancy  based  around  the  group’s 
extensive  experience 

•  A  catalyst  for  improvement  within  the 
Supplier 


•  A  better  understanding  of  BT’s  needs, 
concerns  and  expectations 


•  An  opportunity  to  raise  issues  with  BT 


Increased  visibility  within  BT 


i 


i 


i 
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Software  Supplier  Assessment  Team 


•  Team  of  specialists  first  formed 
in  1990 

•  Multi-disciplinary 

•  Providing  a  portfolio  of  services 


StrCJmmff-SATn» 


Assessment  History 


•  Started  with  proprietary  ‘best 
practice’  audit  technique 

•  Operated  for  two  years 

•  Problems  : 

•  Too  large 

•  Audit 

•  Proprietary 
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Assessment  History  #2 

•  The  solution  is  SSA: 

•  An  assessment  rather  than  audit 
approach 

•  Method  gives  re-use  of  supplier 
data,  flexible,  scaleable  and 
tailorable  assessments 

•  Model  based  on  CMM  which  gave 
Beat  Practice,  good  training 
material,  staged  levels  and  focus 

•  However  Model  expanded  to  fully 
address  BTs  needs 


strcjMHn-iAT'ii  || 

SSA  Ethos  1 

•  It  is  an  assessment,  not  an  audit 

•  All  data  collected  will  be  visible 
only  to  the  assessment  team 

•  All  feedback/information  is  non- 
attributable  to  individuals 

•  To  be  of  any  real  benefit,  there 

needs  to  be  an  open  and  honest 
flow  of  information 

•  We  need  the  support  of  the 

Supplier’s  Senior  Management 

Wednesday  18  lime 
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Tools 


•  Process  description  and  guidelines 

•  Database 

•  Questionnaires 

•  Checklists 

•  Spreadsheets 

•  Project  Management 


S«rCJMi«7-SAT/l* 

Tools  -  Questionnaire 


•  Use  pre  on-site  visit  to  focus 
assessment 

•  SSA  initially  used  CMM 
Questionnaire 


SIfC  jMW9T-&*T/tT 


Tools  -  Questionnaire 


•  SSA  currently  uses; 

•  STARTS-based  questionnaire  -  4 
pages,  50  questions,  20  minutes 

•  Larger  sample  (t5T[)ically  35+) 

•  Completed  by  all  levels 

•  Not  process  bound  -  gives 
‘cultural  feel’ 

•  Statement  based  with  Strongly 
Agree  to  Strongly  Disagree  scale 
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Capability  -  the  3  P's 


Process  Rating 


SVC  jMi  n  -  &ATai 

Capability  Score  -  People 

•  An  indicator  of  the  quality  of  the 
supplier’s  software  development  people 
and  their  ability  to  ‘do  the  job’ 

•  The  rating  profiles: 

•  Company  policy  &  strategy 

•  Leadership  &  management  style 

•  Project  level  people  management 

•  Company  culture 

•  Application  and  Environment 


People  Scoring 
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Capability  Score  -  Performance 

•  An  indicator  of  the  supplier’s 
ability  to  develop  and  deliver 
quality  software  rich  systems 

•  The  rating  profiles: 

•  Pre-contract  performance 

•  In-contract  performance 

•  Post-contract  performance 


Performance  Scoring 


Frequency  Frequency 


SVC  Jm  «7  •  fc*T/t5 


Current  Perception 


CapAbihty  Score  t«  toe  aum  gf  the  PesCocAance. 
^ruceM  and  People  mrw  The  maamua  «ore  u 
I  and  •  High  Scot*  ahuuid  equate  to  Low  Riak 


sire  jMef7-SAT/M 


Distributions 
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Where  To  Now? 


•  Evolve  Model,  Method  and 
Toolset 

•  Migrate  from  CMM  to  become 
SPICE  compliant 

•  Increase  effectiveness  of  People 
and  Performance  elements 

•  Increase  (broaden)  use  of 
Supplier  Assessments  within 
BT 
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Software  Quality 


►  Implementing  and 
Enhancing  a  Quality 
Management  System 
using  Total  Quality 
Management 
Principles  and  the 
Capability  Maturity 
Model  as  a  Framework 

►  Based  on  Practical 
Experience  (1992-97) 


'  ■  f 


Objectives 

^  Share  my  Experiences 
^  Provident 

•  In-House 
Development 

►  PanCredit 

•  Software  House 

►  An  Approach  that 
Works 


.A'- 
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Branch  Info.  System 


►  200  Branches 

^  Unsecured  Loans 

►  Domination  of  Mkt 
(60%) 

►  In-House  Development 

►  60  Staff 

►  Mentality  to  Develop 
Everything 

►  Emphasis  on  Selecting 
Cheapest  Solution 


.'@S( 


Effort  on  B.I.S. 


omm  4.3  ptsTrwuTtow  of  sfort  on  bs 
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ANAlYSaOESGN 


TOGAMMIINC 

1S% 


:.4>. 


S _ •  . 

-.r:  *r*Lv' 


Wednesday  18  |une 


(C309c)  S-2 


Reasons 


*  Unplanned 
Commitments 

►  Poor  Requirements 
Capture 

^  Problems  of  Scale 

►  Culture  of  Fear 

►  Gurus 

►  Silver  Bullet 

^  No  Quality  Assurance 
and  Control 

►  Poor  Configuration 
Mgt. 


¥ 


Effort  on  C.D. 


OKA  PM  4.4  OItTMISUTION  OF  EFFOKT  ON  CD 


ENHANCCMCNTS  STSATtOV 
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Key  Comparisons  C- 


►  Re-Work  (60%  to  18%) 
^  Effort  before  Build 

•  (12%  to  44%) 

^  Enhancement 

•  (1  5  yrs  to  25  yrs) 

►  Requirements  Capture 

►  Management  of  Scale 

•  Staff 

•  Programs 


'U' 
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Return  On  Investment 


►  Crosby  Model 

•  Do  It  (Performance) 

•  Test  It  (Appraisal) 

•  Review  It  (Prevention) 

•  Fix  It  (Re-work) 

*  Cost  of  Improvements 
approx.  500  days 

►  Reduced  Re-work 
approx.  5,000  days 

►  R.O.I  =  1:10 


•a. 
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Who  Are  PanCredit? 


►  S.M.B.E  -  £5m  T/0 
^oftware  House 

►  Financial  Lending  Systems 

►  120  Staff 

►  Outskirts  of  Leeds 

►  V.  00  Methodologies 

►  Oracle\G.U.I 


g— Ml 
'‘•‘S 


Foundations  -  T.Q.M 


^  Customer  Requirements 
^  Prevention  not  Detection 
^  Continuous  Improvement 

►  Leadership/Culture 

►  Teamwork 

►  Process  Control 


m 
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Mgt.  Ccmmitinent 

►  Use  Crosby’s  Model 
^  Gather  Data 
^  Present  Status 

^  Frighten  the  Help  Out 
of  Everyone 

►  60-80%  Re-Work 

►  Losing  Key  Customer 

►  Show  Them  How  to 
Get  Out  of  the  Mess 


Assess  Effectiveness 


►  TickIT 

•  Desk  Study  Reports 

•  Pre-Assessrnent 

^  C  M. M  Assessment 

•  Questionnaires 

•  Results  Profile 

•  Findings,  Action  Plan 
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Identify  Objectives 

►  Get 
Out  of 
Chaos 


m 
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Determine  Strategy 


*  Select  Framework 

•  TickIT 

•  C.M.M 

>  Configuration  Mgt. 

^  Project  Mgt. 

•  Estimating 

•  Risk 

•  Planning  and  Control 
^  Quality  Management 

•  QC  and  QA 


Determine  Resources 


t 


►  Management 
Responsibility 

^  Quality  Assurance 
•  Peers 


^  Process  Improvement 
Group  J 

•  Life  Cycle 


Quality  Circle 


A  \  ^ 
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Results 


►  TickIT 

•  Pass 

•  6  Minor  Actions 

►  C.M.M 

•  Chaotic 

•  Compliance  in  1 1  out 
of  12  Relevant  Key 
Performance  Areas 

•  Good  in  Comparison 


I  u  lefcviMwfc  mi 
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CMM  Assessment  Findings 


PROJECT: 


CMMUvel2,3.4and5 
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Norv-coinpMn  Paritai  compkanc*  FuH  compMnca 


Requirements  Manaqement  -jf 
Software  Project  Planning 
Project  Tracking  and  Oversight 
I  —Software  Subcontract  Management  -f 
Software  Quality  Assurance 
Software  Configuration  Management 
Organuation  Process  Focus 
Organisation  Process  Definition 
L3  Training  Program 

Integrated  Software  Management 
Software  Product  Engineering 
Intergroup  Coordination 
Peer  Reviews 


I  II  iw«t 
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Results 


I  It  lOMwdi  im 


k 


► 


► 


Customer  (30%  re-Work) 

•  Implementation  Issues 


D  C  S  (1.2) 

•  No  Major  Faults  after 
Implementation 

Independent  Q.A  of  0.0 
Process  -  no  Major  Issues 
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Key  Success  Factors 

►  Management  Commitment 
^  T.Q.M  Principles 
*  TickIT  and  C.M.M  as  Framework 


T3. 


Key  Challenges 


►  Leadership 

•  Delivery  vs  Quality 

^  Teamwork 
^  People  Affairs 
^  Customer  Pressure 
^  Overcommitment 


.  '-"I* 
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THURSDAY  19TH  JUNE 


IntiwJuiction 

Chris  UnMr,  Head  of  Development  Process  ImproMnnent  for  the  Lloyds  TSB  vriil  inbpdu^  die  Morning's 
d^ing  spiers. 


Time  OPENING  SPEAKERS 

09.00  CoOuir;  Chris  Lamer,  Lloyds  TSB  Croup  4  Bill  Peterson,  SEI  C401 

09.10  SEI  Process  2000:  Building  on  Strength  C402 

Steve  Cross,  SEI 

09.50  The  Improvement  Engine  of  the  Ericsson  Systems  Software  Initiative  C403 

jorma  Mobrin  £.  Anders  Wasterlid,  Ericsson 

10.30  Break 


Keynotes  -  Track  A 

n.OO  C404a 

SPI  loumey  from  Level  1  to  Level  5 

lohn  Vu,  The  Boeing  Company 


1 1 .45  C405a 

A  Quarter  Century  of  Software  Process  Improvement 

Terry  R.  Snyder,  Hughes  A(rcraft  Company 


Keynotes -Track  B 

C404b 

Highlights  and  Report  Back  from  The  Measurement 

Symposium 

Paul  Goodman,  TBL 

C405b 

Continuous  Quality  Improvement  in  Software  Development  on 
the  Basis  of  Measurement  and  Assessment 

Holger  Gunther,  Allianz  Life 


12.30 


LUNCH 


TtackA  TrackB  TraefcC 

14.00  C406a  C406b  C406c 

Overcoming  ResistaiKe  to  Change  to  A  Co-ordinated  Approach  to  Identifying  Five  Years'  Experience  with  SPI: 

Become  a  True  'learning  Organisation'  Software  Development  Risk  in  MoD  lessons  learnt 

Alistair  Watters,  Warwick  Consulting  Ltd  Projects  Gilles  des  Rochettes,  Thomson-CSF 

Llewelyn  jones,  MoD  4  John  Hamilton, 

DERA 


14.45  C407a 

From  Chaos  to  Control 

Debbie  Hellmann  4  Alf  Pilgrim,  Digital 


C407b  C407c 

The  Complententary  Aspects  of  Process  Software  Best  Practice:  Benefits  to  the 
Capability  and  Re-Use  Capability  Business 

Sergio  Bandinelli  4  Alvaro  Sanz  Alejandro  Moya,  European  Commission 

Monaslerio,  European  Software  Institute 


15.30 


Break 


16.00  C408  PANEL  -  Chaired  by  Colin  Tully,  Colin  Tully  Associates 

Panellists:  Bill  Peterson,  SEI;  Chris  Lamer,  Lloyds  TSB  Croup;  Hans-Jurgen  Kugler,  ESI;  Keith  Jackson,  TBL; 
Alejandro  Moya,  European  Commission;  Hans  Sassenburg,  Netherlands  SPIN  (SPIder) 


17.00 


CLOSE 


SEI  Process  2000: 
Building  on  Strength 


Mission 

Provide  leadership  in  advancing  the  state 
of  the  practice  of  software  engineering  to 
improve  the  quality 
of  systems  that 
depend  on  software. 


Outline 


SEI  overview 


Trends  impacting  software  engineering 
A  vision  of  the  future 
Case  study  (in  the  future  tense) 
Challenges  and  opportunities 


Software  Engineering  Institute 


U.S.  Department  of  Defense  (DoD)  federally 
funded  research  and  development  center 
(FFRDC) 

College  level  unit  at  Carnegie  Mellon 
University  (CMU) 

Applied  research,  education,  and 
technology  transition  programs 
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Software  Engineering  Handles 
‘Trecedented’’  Systems  Well 

Precedented  systems  are  characterized  by 
•an  experienced  development  team 
•well  defined  processes 
•known  requirements 
•domain  experience 
-system 
-architecture 
-technology 


Trends  in  a  Ranidly  Changing 
World 

Explosive  growth  and  use  of  the  Internet  &  Intranet 
Large  companies  downsizing  and  outsourcing 
Increase  in  number  of  smaller  software  companies 
Rise  of  the  virtual  organization 
Increasing  number  of  “knowledge  workers" 

No  end  in  sight  to  advances  in  computer  speed, 
memory  size,  decreased  hardware  costs,  etc.  . . . 

Age  of  information  appliances  and  network- 
centered  computing 

Demand  for  software  escalating 

Surviving  in  marketplace  means  first  to  market 


► 
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Towards  a  Vision  for  SWE  2000+ 

Support  higher  maturity  organizations. 

Realize  many  of  these  will  be  virtual 

organizations  operating  as  Integrated  Product 

Teams  (IPTs). 

The  number  of  such  organizations  will  increase. 

The  SWE  challenge  is  to 

•support  the  definition  and  design  of  processes 
to  meet  business  objectives 

•respond  to  user  needs  at  Internet  time  (three 
to  six  month  cycles) 

•provide  “finger  tip”  access  to  “online,  how-to” 
knowledge 


Strategy 


Technology 
Maturation  & 
Transition  . 


Improve  Software 
^  Engineering  Practice 


i  Process 


Enhanced 

Management 

Capability 

•  management 
discipline 


Change 


Transition 

Readiness 


accelerating 

transition 


Product 


Technical 

Engineering 

Practices 

•  engineering 
discipline 
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Engineered  Software  Systems 


PMODUCT  INSIGHT 


Engilwsling  InsIgM  and  Oiselptina 


PNOCESS  INSIGHT 
Managamtnl  Insight  and  Dlscipllns 


COTS-  OapandaMa  Pfoduet  Lins  I  Psrsonal  CapabHMy  AegutstUon 

Basad  Systsnis  Praclica  '  Sottwara  MatuiUy  Rm 


Systams  Upgrada 

AfChkaetura 


ModaHng  Managamant 


Component-bas«d, 
evolvable  product  linas. 


Acealaratlng 

Softwara 

Tachnology 

Adoption 


built  and  acquirod  with 
predictabla  and  improvad 
coat,  achadula,  and  quality. 


Softwara 

Enginaaitng 

Maasuramant 
a  Analyala 


Supporting 

CoNaboiattPo 

Procaaaaa 


Will  the  following  case  study  be 
possible  by  the  year  2001? 
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Press  Release 


m  Amsterdam  —  Today,  June  19, 2001,  the  21st 
Century  Corporation  (TFC)  announced  that  it 
has  joined  the  elite  25%  of  organizations 
assessed  at  or  above  SEl  Maturity  Level  4 
relative  to  an  integrated  reference  model 
based  on  the  Software/People/Integrated 
Product  Development  CMMs. 
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Annual  Report 


*  The  fiscal  year-end  2001  results  for  TFC  vrere 
released  today,  and  they  reflect  the  following 
improved  results: 

-  Delivery  cycle-time  reduced  43%  AND  customer 
acceptance  of  new  product  introductions  UP  57%. 

-  Field  maintenance  activity  reduced  84%  AND 
customer  satisfaction  survey  results  of  99.4%,  UP 
from  88%  in  1997. 

-  Productivity  improvement  of  54%  AND  employee 
morale  index  UP  34%  to  a  mean  of  9.4  out  of  10. 
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Annual  Report  -  2 


X  The  impact  on  the  business  bottom  line  is: 

-  more  than  a  doubling  of  profits 

-  3-for-l  stock  split 

-  25%  increase  in  dividend  payments 

-  10,000  ECU  bonus  for  all  employees 


Let’s  Look  Inside 
TFC 


^  TFC,  an  adopter  of  the  SEFs  major  initiatives 
for  several  years,  has  been  contacted  to 
renegotiate  the  contract  for  a  product  in  its 
procurement  systems  product  line. 

^  The  product  is  currently  in  design  stage, 
having  already  passed  through  architecture 
review.  The  Integrated  Product  Team  (IPT) 
is  called  together  for  a  meeting. 
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Subject  of 
Renegotiation 


*  TFC’s  customer  has  had  one  of  its  business 
systems  invaded  by  cyber-thieves. 

»  Thanks  to  CERT^,  were  able  to  repel  invasion. 

*  TEC’s  Automated  Buying  System  (ABS)  not  hit, 
because  the  version  was  in  a  secure  facility  (local- 
area).  Concerned  that  security  requirements  are 
inadequate  for  a  broad-based  version. 

*  Bottom  line:  customer  wants  to  add  security 
requirements  to  existing  contract. 


« 


Reievant 
I  Requirements 


*  Security  Trust  Level  X  for  ABS. 

*  Zero  downtime  for  security  upgrades. 

-  customer  is  a  global  operation  with  24-hour  activity 
on  its  ABS. 

«  Minimize  additional  cost  to  reach  Security 
Level  X. 

*  No  degradation  to  security  level  because  of 
geographical  distribution  of  the  new  system. 
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Considerations 


*  How  do  security  enhancements  fit  with  rest  of 
product  line? 

*  What  is  our  process  capability,  and  what  are 
the  risks  to  dependability  requirement? 

*  What  improvements  are  coming  that  might 
change  current  approach/capability? 

*  What  is  the  interaction  between  wide-area 
collaboration,  upgrading  a  system,  and 
maintaining  current  level  of  security. 
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Product  Line  Notes 


Vendor  A  and  TFC  discussed  opportunities  for 
enhancing  security  on  Vendor  A’s  component 
before  the  last  architecture  revision; 
prohibitive  development  cost  based  on  current 
market  potential,  productivity/quality  rates  for 
new  technology  additions,  and  early  prototypes 
caused  shelving  of  the  effort. 

TFC  has  other  business  system  product  lines 
with  emerging  security  issues;  one  question  is 
whether  TFC  should  start  up  another  product 
line  of  security  add-ins. 


« 


« 


« 
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Process  Capability 
Notes 


»  PSP/TSP  data  for  entering  a  new  technology  area 
(security)  is  available  for  both  TFC  and  its 
vendors. 

«  Organizational  process  capability  for  the  product 
line  accounts  for  technology  enhancement  as  a 
risk  factor. 

*  Consideration  of  a  security  product  line  would 
necessitate  piloting  a  prototype  to  get  some  initial 
productivity  baselines  to  map  against  the 
organizational  standards  for  creating  a  new 
product  line. 
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Potential 

Improvement  Notes 


»  As  an  SEIR  subscriber,  TFC  has  access  to  online 
comparison  data;  industry  standards  for 
productivity,  quality,  and  cost  by  maturity  level; 
business  sector/application  type;  and  advanced 
information  on  piloting  opportunities  with  the 
SEI. 

*  TFC’s  intranet,  based  on  the  SEl’s  IDEAL®** 
repository  concept,  contains  information  on 
TFC  initiatives  in  technology  and  process 
improvement,  allowing  them  to  access  potential 
internal  pilot  solicitations. 


« 


« 


« 


« 


Supporting  Collaborative 
Processes  Notes 


*  A  specific  approach  to  wide-area 
communications  and  information  sharing  has 
already  been  designed.  How  will  this  be  affected 
by  the  stringent  security  requirements? 

»  How  does  the  interaction  between  the  activity 
during  global  collaboration  and  new  system 
synchronization  during  the  system  upgrade 
effect  the  current  processes? 

*  How  will  improvements  and  collaborations  be 
tailored  in  conducting  future  business  in  a  global 
marketplace? 
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Results 


Challenges  and  Opportunities 

How  can  we  accelerate  process 
improvement? 

Can  we  design  processes  to  meet  the 
business  needs  of  dynamic  organizations? 

Can  we  support  process  definition  and 
improvement  in  small  companies?  For 
integrated  product  teams? 
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Qualitative  CBA-IPI  Trends 


bteve  Cro!»»,  Ski 


Basis  of  a  New  Process  Model  1 

User 

envision  what  is 
possible 
(scenario-based, 
prototyping, 
new  concept 
of  ops)  ^ 

^  deliver  what  is  needed, 

y  evolve  it  during  the 

X  life  cycle 

X  21st  Century 

X  Program 

X  Office 

(A  Virtual  Organization)  ^ 

Acquirers 

Developers 

integrated  process  models 
insert  what  is  missing 
(technology  base) 

3* 

Summary 

SW-CMM  has  had  a  profound  impact. 

There  is  a  continual  need  to  anticipate  and  be 
proactive  in  a  rapidly  changing  world. 

SEI’s  strategic  plan  is  a  basis  for  the  next 
generation  of  process  improvement. 
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Basic  facts  about  Ericsson 

•  Major  telecom  system  and  mobile  phone 
vendor 

•  Turn  over  ~16  billion  $ 

•  Total  R&D  spending  --3  billion  $ 

•  Present  in  >100  countries 

•  94  000  employees 


ERICSSCN 
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The  role  of  software 


Today  we  spend  about  14 
billion  SEK  on  SW 
development  and  we  have 
more  than  1 0.000  SW 
engineers 

And  the  importance  of  SW 
continues  to  increase  in 
terms  of; 

•  Fraction  of  the  total 
development 

•  Key  enabling  technology 


eSEPOJtM  '9 
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Our  History 


The  various  efforts  we  have  put 
in  do  ft  together ! 


ESSI 


SW  Metrics 


PQT 

Measurements 


Process  Management 


^  PROPS  •  Project  Management 
1988  1989  1990  1991  1992  1993 


ERICSSON  ^ 


ESSI  Purpose: 

improve  customer  satisfaction  and 
software  development  efficiency  by 
radical  improvement  of  software 
quality,  lead-time  precision  and  lead- 
time 


ERICSSON  ^ 
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Reduced  Delays 
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ESSI  Improvement  Engine 


Performance 

monitoring 


CMMI 


Deploynitnt) 


VFA 


Support 


Good 

practice^ 


zr 


PQT  p 


Deploymgul  |  Monitoring 
•Progress 
•Peer  review 


9701 


estPG 
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The  use  of  CMM 

In  general  CMM  is  lised  as  a  toot  to  achieve 
performance.  It  is  not  as  a  goal  jn  it^lf.  : 

Specifically  CMM  is  used  to: 

•  Find  areas  for  improvement 

•  Set  a  basic  principle  for  prioritizing  improvements 

•  Follow-up  on  improvements  before  results  can  be 
measured 

•  Provide  a  guideline  to  an  excellent  software 
organisation 


ERICSSON  $ 
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CMM  Light  &  Ultralight 


Purpose:  get  a  snapshot  of  the  CMM  status 
Recommended  use: 

-  Between  full  assessments  for  improvement  tracking  purposes, 
eg.  quarterly 

-  Prior  to  full  assessment 


CMM  K«y  Pro«««»  Atm  ProMi 

Ivl  I  ivl  <  Lvt  • 


kHrilr.  ] 

1  ■■ 

_ 

iR  ■  ■  ■  ■  ■  IH  __  _  _ 

■  r 

W  M  M  B  BH  B  M  ■  B  Ml 

t3cl: 

Rif  RP  RT  g«  CM  RR  RO  TR  Hi  Rt  K  RR  RH  OM  DR  TC  RC 


ERICSSDN  $ 
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PQT 

PQT  is  the  corporate  metrics  system  to  monitor 
performance  on:  - ~a 

•  Productivity  _ /mm\ 


ERICSSON  S 


Improvement  objective 


Target  Attributes 

Efficwncy  ;  Productivity,  Tima,  Cost  Precision,  Quality 

'The  ability  to  produce  the  right  product  to  the  right  cost  in  the  right  time' 

External  data 

I  Vv  r  IntemaF  data  7 


Process  model 
(Methods  &  tools)  * 


PROCESS 

(project) 


/  Product 
model 

(Architecturs) 


Organisation 


Dellveiad 

Product 


Information 

pyramid 
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Vital  Few  Actions 


The  limited  set  (3+3)  of  high  leverage  actions  that 
will  give  maximum  contribution  to  improved  performance 
in  the  short  to  medium  term 

Breakthrough  Improvement  Actions  (0-1): 

-  New  organisation 

-  Re-engineered  processes 

-  New  Infrastructure 

Continuous  Improvement  Actions  (2-3): 

-  Improvements  within  given  infrastructure 
_ -  Moderate  process  changes _ 


Business  as  Usual 


ERICS 


£SeRGMwi«iM7  23  iMM'' 

Deployment  of  VFA 


EXM  ESSI  progress  report  Q1  1996 

Monitoring 

SUMtiM?Y 

n  Mtrm  twtwt  now  hav*  mngw  to  counttr  th«  rtoart  sal  btdu 
and  that  our  coffacavaadm  art  firwiy  paying  oir  Yatwahava 
aoma  prettama  wdh  aoma  of  ttw  OAU  products  that  naad  anmadaia 
ae&on 

-  progress  reports  ” 

QUALITY 

-  peer  reviews 

MM.r  vam  mb  wbcwk  mmm  mu.t«  /  mma 

\U  .  /J  lljtiim 

Tha  mcara  nrtd  is  promiang  Yet.  tw  FT-igjaa  from  the  AMp9 
projaa  was  not  good  Soma  of  twOSM  product  had  fatildanaiaaa 
aaraghasl.SfaUlaparkNCSS  One  of  the  products  ml  be 
redasignaq  and  tha  two  othaia  wM  have  rananmd  dadt  cfwcto  and 
inspections  to  conaar  Viat 

No  of  participating  organisations  Level  of  deployment 

50  T -  » 

bMOIIO 
■  TMOS 
30--AXE10 


•95  -96 


PD  process  lead-time 


•94  -95  -9< 

No  of  Peer  Reviews 


I  TMOS 


lAXE&MO 


-94  -97 


ESSI  Improvement  Engine 


lornM  Mobrin  &  Anders  Wastcriid,  Ericsson 


The  Improvement  Engine  of  the 
Ericsson  System  Software  Initiative 


ESSI  Good  Practice  characteristics 

•  supports  a  Vital  Few  Actions  or  a  CMM  Key  Process  Area 

•  is  a  packaged  collection  of  practices  from  good  performing 
design  centres 

•  has  performance  indicators  (facts)  which  show  better  than 
average  performance 

•  is  recognized  by  others  (than  the  practice  supplier)  as  a 
"better  than  most"  practice 

•  is  established  and  documented,  before  packaging  starts 

•  has  a  support  organisation 

•  is  promoted  by  means  of  ESSI  Policy  Deployment 

•  has  a  Transfer  support  package 


ERICSSeN  $ 


£S£pc;tfw  10  m? 


LMeOT  WXina  IMMT 
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Summary 


•  The  ESSI  Ir  vement  Engine  delivers 
significantly  improved  business  results 

•  Practices  are  now  transfered  to  other  areas 
in  Ericsson 


iolw  Vu,  toeing 


Software  Process  Improvement  loumcv 
From  level  1  to  Level  S 


Software  Process 
Improvement  Journey 

(From  Level  1  To  Level  5) 

Keynote  Presentation 
at 

The  2nd  European  Software  Engineering  Process  Group  Conference 
Amsterdam  June  16-19, 1997 

Presenter.  JohnO.  Vu 
Associate  Technical  Fellow 
Software  Engineering 
Research  &  Technology 
The  Boeing  Company 

Tho  Boeing  Company 


— 

What  Does  Capability  Maturity  Levels  Means? 


Level  2  by  1992  ...  and  Level  3  by  1993  ...  and  ... 
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Software  Procen  Improvement  loumey 
From  level  1  to  level  5 


Maturity  Levels  Are  Meaningless  ... 

If  They  Cannot  Be  Explained 

In  Terms  Of  Business  Objectives 

•h  Improve  the  quality,  cycle  time,  and  reduce  the 
cost  of  software  activities 

4-  Provide  faster  service,  deliver  higher  quality 
products,  and  achieve  customer  satisfaction 


Tho  Boeing  Company 


Boeing 

Software  Organizations 


The  Booing  Company 

JaftnO-Vn 
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Software  Procces  Imfwovemenl  (oumcy 
From  Level  I  to  level  5 


I 


Maturity  Levels  At  The  Boeing  Company 

Capability  Mature  Levels  are  expressed  in  terms  of 

Assessment  results  (CBA/IPI) 

4-  Business  Improvement  Data: 

Quality 

Cost 

Cycle  Time 

Customer  Satisfaction 


Institutionalization  At  The  Boeing  Company 


To  be  considered  “Institutionalized”  a  process  must  be 


Defined 

Documented 

Practiced 

Measured 

Verified 

Maintained 

Continuously  Improved 


Tho  Booing  Company 
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Mnware  rrocess  improvcmeiM  lourncy 
From  Level  1  to  Level  5 


Level  1:  Our  Lessons  Learned 

Things  we  toft  behind  Things  we  teamsd 


Schedule,  Schedule,  Schedule 
Guesstimate 
Undocumented  practices 
No  measurement 
No  data 

Hurry,  reactive-mode 


Commitment,  Commitment,  Commitment 
Estimate 

Documented  practices 
Basic  project  measurements 
Begin  data  collection 
Be  patient,  pro-active  mode 


Without  management  commitment,  we  never  get  out  of  this  maze 


The  Boeing  Company 


Level  2:  Our  Lessons  Learned  I 


Things  we  left  behind 


Things  we  teamed 


Project  mismanagement 
Schedule  is  fixed 
One  way  to  do  things 
Heroic  effort 
No  facts  &  data 
Unique  situation 
Takes  too  long 


Project  management 
Schedule  is  based  on  estimates 
Variation  exists 
Sharing  of  practices 
Systemic  data  collection 
Common  process 
Maintain  commitment 


We  know  where  we  are,  we  know  how  to  get  there,  and  we  can  repeat  n 
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Level  3;  Our  Lessons  Learned 

Things  we  teamed 
Project  management  robustness 
Product  management 
Identify  and  share  “best  practices” 
Knowledge  transfer 

Common  measurements  across  projects 

Product  quality  focus 

Begin  tracking  product  performance 


We  are  becoming  a  learning  organiaaf  ion  via  sharing  of  “bast  practices'' 


Level  4:  Our  Lessons  Learned 

Things  we  learned 
Project  management  robustness 
Product  management  robustness 
Correlation  between  process  and  product  performance 
Focus  on  cycle  time  arid  productivity 
Additional  measurements 

Process  Management:  Managing  by  facts  and  data 
Begin  Product  Line  Management 


We  are  using  data  to  refine  organization  process  and  improve  product  performance 
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From  Level  1  to  Level  5 


Level  5:  Our  Lessons  Learned 

Thing*  we  leamad 
Project  manageinent  robustnees 
Product  management  robuatneaa 
Proceas  management  robuatneaa 
Product  line  management 
Pocua  on  organizatioruil  capability 
Improve  market  share 
Technology  tranafer 
Begin  to  look  outside  current  business 

Wears  ui 
and  to  exf 

The  Boeing  Company 


ling  organization  capability  to  Improve  market  share 
iloro  new  business  opportunities 


Journey  From  Level  1  to  Level  3 

Boeing  Information  Systems: 

4-  Technology  Planning 
Application  Development  and  Maintenance 
>>■  Telecommunications  Engineering 
4-  Computer  and  Network  Operations 
4-  Multimedia  Services 
Document  and  Records  Management 

Assessment  History: 

Level  1  in  1991 

•h  Level  2  in  1994  (120  Projects  Participated) 

>>■  Level  3  in  1996 

The  Boeing  Company 
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Over/Under  Percentage 


Percent  of  Defect  found  &  fixed 


rrom  Lcvei  i  lo  level  :> 
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Software  Process  Improvement  lourney 
From  Levd  1  to  level  S 


Cost  Savings 

(Documented  through  company  approved  coat  aavings  program) 


Cycle  time 

(Average  time  to  complete  a  request  for  services) 


The  Boeing  Company 

iOlMO  Vv 
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Satisfaction  Survey 


i  lull)  Level  1  lu  Level  j 


Overall  Performance 


Journey  to  Level  5:  Boeing  Defense  &  Space 


18  years  4  years  2  years 


Successful  transition  of  Level  5  processes  to  Space  Transportation  Systems 
in  Boeing  Defense  &  Space  proves  that  development  programs  can  start  at  Level  5 


The  Boeing  Company 

JehaD.Ve 
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Our  Success  Factors 


•V  Management  CommttiiMnt 
>¥  Funding  and  Reaourcec  for  Procesa  Improvement 
4-  Ability,  SWIIs,  Knowledge 
>¥  Measurement  and  Metiica 
Monitoring  Mechanism 
Training  (both  Formal  and  Informal) 

•t-  Culture  of  Engineering  Excellence 
•f  Customer  Participation 


(Based  on  our  Lassons  laamad  on  SoBwars  Procass  Imprevamant) 

The  Boeing  Company 


Process  Maturity  Levels; 
What  Have  They  Improved? 


OlTClplinaO 
Procen 


PrtdIctabI* 
Prectu 


Contkiuowiy  ^  Optimizing  (5)  I 

Improving 

Proe«M  Business 

Opportunities 


Conttatont 

ProcMS 


Defined  (3) 


ManagedjK^J 

CostfCycie  time 


Quaiity  (i.e.  #  Defects) 


JRepeatobl^(2)j 
_ _  Schedule 


Initial  (1) 


(Based  on  our  Lassons  laamad  on  Saftaian  Process  Improvsmanl) 

The  Boeing  Company 

JeaeDiWi 
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Our  Observations 


(PsMd  on  our  imsoim  t—nud  on  SoftMore  ProeoM  Improvonwn  i 

The  Boeing  Company 


— 

Our  Approach 


4-  Integrate  SWE-CMM  and  P-CMM  assessment 
Pilot  completed  Jan.  97  successfully 

•¥  Apply  Personal  Software  Process  (PSP)  to  Level  3  organizations 
On-going  pilots  in  2  Level  3  organizations 

Acquisition-CMM 
On-going  study 

Advanced  Quality  Systems  (AQS)  for  software  suppliers 
45  suppliers  participated 
25  suppliers  advancing  to  next  stage 


The  Boeing  Company 


9 


ThursdiY  19  |un« 


(C404a)  S-1S 


We  Believe 


There  is  a  svstenutic  approach  to  improve  the 
way  software  is  developed  and  maintained. 

There  are  stages  of  process  maturity  in  which  the 
organization  will  improve  by  following  a 
recommended  sequence  to  decrease  risk  and 
increase  software  performance. 


By  following  an  evolutionary  path  the 
organization  will  continuously  improve  their 
business  objectives  by  producing  better,  faster, 
and  higher  quality  products,  and  achieve 
customer  satisfaction. 


Th«  Boeing  Company 


Conclusion 


The  software  industry  must  express  process  improvement 
in  terms  of 

Business  Improvement  Data: 

Quality 

•  Cost  [ 

; mT  Cycle  Time 

T 

■  Customer  Satisfaction 


And  use  Capability  Maturity  Levels  only  as  street  signs 
on  the  process  improvement  journey 


The  Boeing  Company 
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Highlights  and  Report  Back  from 
The  Measurement  Symposium 

Paul  Goodman,  TBL 


This  presentation  will  be  developed  at  the  conference  following  the  Measurement 
Symposium  on  Tuesday  IT"*  June.  The  material  will  be  made  available  to  delegates  at 
the  start  of  the  session  for  inclusion  in  the  handout  folder. 


Paul  Goodman,  Chairman  of  Tuesday's  Measurement  Symposium,  will  present  highlights 
from  the  day's  proceedings.  Drawing  from  the  rich  variety  of  presentations  which  feature 
many  of  the  leading  experts  in  the  field  of  metrics,  Paul  will  extract  lessons  learnt,  latest 

thinking  and  current  best  practice. 
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The  Early  Years:  1972  •  1976  (CPL) 


HUGHES 


Measurement 

*  Lessons  Learned  Reports 
'  Historit^Otita  Kotebook 
•Fcedbe^^U^lirly^ 

■TsS..  ^ 


‘Assasspiat^  Tbrough 


Results 

•  Formal  Procedures 

■  Action 

'SPM  Course 


•SomeU|)|i?S®^ 
•Morihpown: 


*^t)ol56ind 
Things  Wortt? 

What  Is  Important? 
90%  Syndrome  with 
Gantt  Charts 


i 
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Establishing  the  Culture: 
1977  - 1986  (SED) 


HUGHES 


Ready  for  a  Paradigm  Shift 


AMhiieFoninlVmianof  . 


•  PowcrM  Coapattn 
•Tirget>  DevciopBratOK! 
•COfs  Hardware  aad  Sollwarc 
» A'Pewdeaf  liiprewiKal  la  , 


*  Slow,  Limited  Memdty 
•Nao-oonrs 

*  Debug  Hardware  and 
Software  Together 


i 


e 


e 
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Example  Results  of 
Process  Improvement 


HUGHES 


1988  1989  1990  1991 


CPI  (Cost  Performance  Index)  - 
Earned  /  Actual 

SPI  (Schedule  Performance  Index) 
=  Earned  /  Planned  (or  Scheduled) 

Values  over  1.0  are  below  cost  ft 
ahead  of  schedule 

In  1990  (first  year  after  Level  3 
process  maturity),  saving  of  $2 
Million  on  an  annual  basis 

One-year  ROI  of  5:1  based  on 
process  improvement  investment 


Growing  the  Culture: 
1991  -  Present  (Hughes) 


1 


HUGHES 


The  Growth 
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How  We  Operate: 

Systems  and  Software  Engineering 


HUGHES 


i  *  Technology 
Training  Insertion  . 


Engineering 
Process  Group  (EPG) 


Prpjwt  Schedule 

Reporting  Quality 


Root  Cause  Analysis 


Historical 

Data 


V  CSWP/ 
i  CSEP, 


Predictions 


Project  Reporting  with 
Metrics  is  a  Key  issue 


HUGHES 


Practice 

3 

Procedures 

3.2.1 

3.2.2 

3.2.3 

3.2.4 

3.2.5 

3.2.6 

3.2.7 

3.2.8 

3.2.9 

3.2.10 

3.2.11 

3.2.12 

3.2.13 

3.2.14 

3.2.15 

3.2.16 

3.2.17 

3.2.18 

3.2.19 

3.2.20 


Project  Reporting 


Project  Overview . 

AccompHshments  Summary, 

Problem  Summary . . . . 

Project  Schedule . 

Risk  Status . 


r:. 

-  Many  "Practices” 
Each  with  Supporting 
"Procedures” 


. . 

«  J  a  e  •  eV 


Milestone . . . (MEDICS 


IMETRICS) 

(METRICS) 


Rate  Chart . . . (METRICS) 

‘  Earned  Value . iV.'i’fS  iMETRlCS) 

Target  System  Resource  l|MEmCS) 

Software  Project  Resolved  Eoraoiwi^^’V’‘i  > 
i  Financial/ Staffing... 

^  QualKy^ndlcator^ ..... .  ,‘;.N 

i  Software  PrableiTw'8Miw^''!%^^W^^^^^H 

j  Prodwtt^  Measuteineiiteaj^pi|||W||li|g^ 

■  Software  Management  EffiMffiywpnRMN^m® 
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Improving  the 

Common  Engineering  Process 


HUGHES 


Contract 


•  cmi  learns 

•  IR&D 

•  Initiatives 

•  Benchtrending 


Defects  and  Review  Efficiency  I 

1 

R 

p 

D 

c 

u 

j- , 

RA 

84.0% 

PD 

XX  x% 

XX.  x% 

-  - 

DD 

XX  x% 

XX. x% 

XX.  x% 

XXJI% 

»CJC%* 

C 

Ph9«a 

XX  x% 

xx.x% 

xx.x% 

XX  x% 

XX.X% 

-  > 

Detected  UT 

xx.x% 

XX  x% 

XX  x% 

XX  x% 

KUflIk 

IT 
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XX  x% 

XX  x« 

XX.X% 

xxx% 

XXJ(% 

FT 
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XX.X% 

xx.x% 
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XXJ*% 
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XXJ(% 
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Pi 
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ProcMs  ; 
bnpravement  - 
trenci 


IPI  : 

AssMtment 
at  LeMel3i"f 


i  y  /  tesessment 

Assassment  /  ai  Level  3* 
at  Level  2  AMMsmenf 
at  Level  3  : 


1970  1975 


1980  1985  1990  1995  2000 


000  200  WA 

•OO  000  tooo  001 

i»0  m 
»7»  m 


Truth  3: 

Key  Process  Characteristics 


HUGHES 


Truth  4: 

Pick  Best  Practice 


HUGHES 


Take  some  existing  standard  and  Just  adopt  it ...  then  improve  it 


*  Don’t  try  to  innovate,  at  least  not  right  away 

*  Don’t  try  to  “combine  the  best”  of  several  practices  ' 

*  Do  Improve;  after  deployment  and  project  experience 

*  Do  adopt;  internal,  benchmarking  or  from  the  literature 

*  Do  share;  benchmarking  and  publishing  gets  feedback 


S 
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Truth  5: 
Quality 


tTTrSG. 


Quality  la:  Quality  la  not: 

•  A  parvaaiva  way  of  life  •  Quality  cops 

•  A  maaaura  of  individual  integrity  •  A  quality  aasuranca 

and  pride  or^nization 

•  An  organization  of  quality  people 

•  What  it  takas  to  meet  our  customers’  expectations 

•  What  it  takas  to  meat  our  employees'  expectations 

•  What  It  takes  for  othera  to  acknowledge  us  as  a  leader 


Build  quality  into  the  processi 


Truth  6; 

Discipline  is  Key 


HUGHES 


*  Reward  the  followers,  especially  problem<evoider8 

*  Admonish  the  naysayers 

*  Project  reviews  are  vital 

*  Reviews  must  be  by  managers  who: 

-  Have  authority  to  cause  change 

-  Believe  In  disciplined  software  process 

-  Are  relentless  ’ 


Focus  on  Process  for  Success 


1 


HUGHES 


•  There  is  a  process  - 

•  The  process  has  a  respoasibk  owner 

•  The  process  is  documented  £  . 

•  There  is  training  for  the  process  4  , 

■  The  process  is  under  control 

•  The  process  has  a  mechanism  for  cont|piwa9'4ija]^l3l9BH| 

•  The  process  is  followed 


Current  Issues  and  Concerns 


HUGHES 


Systems  Engineering 
Project  Management 


Technoiogy  investment 


eswp/ 

jeSEP^ 


Software  Engineering 


Product  Development 
Process 


•  Methods 

•  Tools 

•  Technique^ 


Tailor 

a*^ 

for  Project 

Sizs 

» 
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Allianz  Lebensversicherungs-AG 


Galilei;  “Measure  what  is  measurable 
and  what’s  not  measurable 
try  to  make  it  measurable” 


Lord  Kelvin: 

"The  degree  to  which  you  can 
express  something  in  numbers 
is  the  degree  to  which  you 
really  understand  it” 

Tom  DeMarco; 

“You  can  not  control 
what  you  can  not  measure” 

(You  can't  manage 
what  you  can’t  control)” 
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Quality 


Magic  Triangle  of  AD 
Time 


mmm 


Metrics? 


Cost 

DM 

$ 
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Motivation  for  AZL 


•  huge  investments  in  C/S-Application  Development 

-  technology 

-  process 

-  people 

r~|^  acceleration  of  the  maturity-process 


5 


Allianz  Lebensversicherungs-AG 


philosophy 

•  first  understand  then  make  changes 

•  process  changes  must  be  driven  by 

-  specific  goals! 

-  characteristics  of  the  environment 

-  product  attributes 

-  experimental  approach 

•  incremental  and  provable  changes! 


» 
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Allianz  Lebensversicherungs-AG 


prodecure 

•  quantify  the  quality  of  products  and 
processes  with  help  of  metrics 

•  understand  the  current  situation 

•  identify  and  implement  imoroyements 

•  eyaluate  progress 

•  structure  experience 

•  imoroye  continuously  the  maturity  of  products 
and  processes 


i 


i 


i 


i 


« 


« 
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definition  of  aggregation  levels 


Allianz  Lebensversicherungs-AG 


GQM-Cataloaue  of  AZL 


analysis 
of  the 

AD-process 


analysis 
of  the 

AD-products 


[Zl|^  effort  distribution 


stability  of  business-requirements 

flexibility  in  the  development 

and  administration 

of  insurance  products _ 

maintainability 


Allianz  Lebensversicherungs-AG 


Goal;  G200;  Increase  stability  of  business  requirements 


Question:  Q208:  How  many  changes  were  requested  in 
the  implementation  phase 


Metrics;  M245;  Number  of  defects  concerning 
program  changes 

M246;  Number  of  defects  concerning  specification 
M247:  Number  of  defects  concerning  environment 
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Allianz  Lebensversicherungs-AG 

distribution  of  defects 


Project  A  Project  B  Project  C 

(43PM.  88DEF)  (13PM,  35DEF)  (11PM,  10DEF) 


□  specification  ^  program  □  environment 


1.1 


Allianz  Lebensversicherungs-AG 


F210:  How  was  the  business  preparation 
of  the  project? 


Semantic 


metrics 

(+)  profile  of  stability  (-) 

of  metric 

M235  (months) 

^12 

between  study 
and  DTOiect 

M236  (number)  | 

continuity  ol  people 

M237  (number) 

business-specialists 

M238  (number) 

^ ^  1 

IS-spedalists 

M239  (scale) 

4«c - 

business  documents 

M240  (J/N) 

kick-off-meeting 

M244  (number) 

internal  cooperation 

M253  (number)  g 

external  cooperation 
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Performance-T est 

5 


Integration- 

Test 


Case-Tool 


Unit- 

Test 


Form-Generation 


Code-Generation 
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risk-profile 


IP 

u 

1 

_ 1 

12 

.3 

'Ml 

17  18  19 

21  22 

2S  27  28  29  31  12  ispxps 

36  S9  4112 

13  4il9 

bn 

iilMiP 

1  high  2  extreme 

R1 1  critical  deadlines  (time  txjundaries) 

R13  knowlege  monopoly  at  project  critical  positions 

R14  still  pending  decisions 

R15  influence  of  parallel  projects 

R16  cooperation  with  externals 

R23  performance  requirements 

R25  reusability 

R42  premises  unclear 
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Allianz  Lebensversicherungs-AG 

Goal-Definition-Scheme: 

•  Object; 

Application  Development  Process 

•  Purpose; 

Characterize 

•  Aspect; 

effort  distribution  including  rework 

•  Viewpoint; 

Project  leader 

•  Context; 

Allianz  Life  (Host-AD) 

18 
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Abstraction  sheet 

Qa  (Quality  aspect): 

Influence  factors  (IF): 

effort  distribution  including  rework  in 

•  experience  of  project  group  (IF1) 

•Analysis  (A) 

•  availability  of  resources  (IF2) 

•  Design  (D) 

•  stability  of  business-reguirements  (tF3) 

•  Realization  (R) 

a 

•  Implementation  (1) 

* 

Influence  on  Quality? 

(1)  Qa~1/1F1 

(2)  Qa  -  1/IF2 

(3)  Qa~  1/IF3 


20 
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Focus  on  projects  with  the  followin( 
characteristics 


similar  projects/applications  in  the  future,  which  can  profit 
from  experience 

Pilot  projects,  which  introduce  new  technologies,  processes 
or  methodologies 
-  Goal;  Shorten  the  maturity  period 


Allianz  Lebensversicherungs-AG 


approach  is  widely  accepted 

it  brings  value  even  to  the  pilot-projects 

we  are  now  in  the  phase  of  improvement 

we  have  developed  tools  (experience  database,  etc.) 

we  want  to  establish  basic  metrics  for  all  projects 

we  even  want  to  establish  the  QIP-  and  GQM-approach 

outside  the  application-development-environment 
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Warwick 

ConsuKing 
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Overcoming  Resistance 


Overcoming  resistance  to  change  in 
SPI  environments  to  become  a  true 
‘learning  organisation’. 

C  Copyright  Alistair  Watters  1997  Alt  Rights  Reserved 


Introduction 


...  I  went  to  the  woods  because  I  wished  to  live  deliberately,  to  front 
only  the  essential  facts  of  life,  and  see  if  I  could  not  learn  what  it  had 
to  teach,  and  not,  when  I  came  to  die,  discover  that  i  had  not  lived.  I 
did  not  wish  to  live  what  was  not  life,  living  is  so  dear;  nor  did  I 
wish  to  practise  resignation,  unless  it  was  quite  necessary.  I  wanted 
to  live  deep  and  suck  out  all  the  marrow  of  life,  to  live  so  sturdily 
and  Spartan-like  as  to  put  to  rout  all  that  was  not  life,  to  cut  a  broad 
swath  and  shave  close,  to  drive  life  into  a  corner,  and  reduce  it  to  its 
lowest  terms,  and.  if  it  proved  to  be  mean,  why  then  to  get  the  whole 
and  genuine  meanness  of  it,  and  publish  its  meanness  to  the  world; 
or  if  it  were  sublime,  to  know  it  by  experience,  and  be  able  to  give  a 
true  account  of  it  in  my  next  excursion.  For  most  men,  it  appears  to 
me,  are  in  a  strange  uncertainty  about  it,  whether  it  is  of  the  devil  or 
of  God,  and  have  -■.-imewhat  hastily  concluded  that  it  is  the  chief  end 
of  man  here  to  "glorify  God  and  enjoy  him  forever."  ... 

Henry  David  Thoreau 


•  CopvngMAfMwrWMOVlM?  Al  RigMt  AtMrwd 
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Introduction 

♦  Resistance  is  a  problem  in  all  change 
initiatives. 

♦  Resistance  can  be  both  covert  and  overt. 

♦  Resistance  to  change  costs  organisations 
millions  of  pounds  each  year. 

♦  Implementation  ‘models’  do  not,  and  can 
not,  solve  the  problem. 


•  CopvngMAMarVMMnlM?  AiMg^AtMnM 


Chaos,  Systems  and 
Change 

♦  Each  element  of  a  system  embodies  and 
reflects  every  other  element. 

♦  A  chaotic  element  cannot  be  stabilised  by 
another  chaotic  element. 

Chaos  found  at  one  level  of  a  system  will  be 
present  at  all  other  levels  within  the  system. 

•f  Human  thought  and  cognition  is  a  central 
element  of  any  changing  system. 


•  UKgMintMfWd 
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The  ongoing  problem  of 
resistance 

-f  ‘Static  Mechanisms’ 

••  Homeo-static; 

■»  Socio-static; 

■»  Enviro-static;  and 
«  Cognito-static. 

♦  Levels  of  Change 

•  1  St  Level  Change  -  Evolutionary  Change; 

2nd  Level  Change  -  Revolutionary  Change;  and 
••3rd  Level  Change  -  Changing  the  Change  Process. 


eCopynoMAfesurVWalan  1M7  AIRgMtfiMnM 
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Why  is  the  Rate  of  Change 
Increasing? 

♦  Information  Technology 

♦  Communications 
Transportation 

♦  Media 

«CapyrgMAaAarWM«s  1M7  AiAgMsReMTMd  7 
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i 


i 
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Controi  of  Resistance 


>  Resistance  is  under  perceptual  and  cognitive 
control, 

♦  The  perceptual  and  cognitive  apparatus  of 
an  individual  can  be  ‘re-tuned’. 

♦  3rd  Level  Cybernetic  Change  abolishes 
resistance  and  establishes  learning  by 
changing  the  process  of  changing. 


eCopyngMAIMrt^Mars  >997  A>  RlgMs  R«Mn«9 
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The  Structure  and  Process 
of  Resistance 

♦  Resistance  has  a  definite  structure  and 
process  that  can  be  elicited  and  ‘mapped’ 
like  any  other  business  process. 

‘  ♦  The  structure  and  process  of  resistance  is 
absolutely  unique  to  an  organisation. 

♦  This  structure  and  process  is  the  same 
regardless  of  the  type  of  change  being 
implemented. 

OCopynBMAaMavWaCM  1M7  At  RqNs  AnarvoO 


Mapping  the  Structure  & 
Process  of  Resistance 

♦  Resistance  is  a  combination  of ‘real’  things 
not  just  an  abstract  term.  Deal  with 
specifics  that  can  be  measured. 

If  you  have  ‘the  right’  information,  change 
becomes  simpler  and  quicker. 

♦  A  complete  set  of  data  is  needed  including: 

‘The  What’  -  Descriptions  &  Behaviours; 

‘The  How’  -  Explanations  &  Processes;  and 
■*  ‘The  Why’  -  Justifications  &  Reasons. 


ACopynoMAitts»WM«S19f7  Ai  R«gM»  Rtssnod 
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Culture,  Resistance  &  SPI 

♦  Culture  plays  a  central  role  in  SPI. 

♦  CMM  /  P-CMM  /  ‘IDEAL’  /  SPICE  are  all 
retrospective  construct  models.  They 
cannot  be  used  to  implement  cultural 
change  -  no  generic  ‘model’  can. 

♦  The  only  ‘how  to’  implementation  model 
that  will  work  is  one  that  is  specific  to  an 
individual  organisation. 


e  CopynaM  AMUr  WM«s  tM7  Ml  Resened 


Why  Bother? 

♦  All  forms  of  change  including  SPI  are 
expensive  to  implement. 

♦  Resistance  increases  the  cost  of  change 
implementations  on  average  by  400%. 

♦  Change  becomes  increasingly  more  difficult 
after  each  ‘failure’. 

♦  Measurement  and  tracking  of  change 
becomes  possible. 


OCopyngtit  AfesurWMvs  1*97  Al  Rights  RtMivod 
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Tools  for  Overcoming 
%  Resistance 


o  Training  with  ‘covert’  change; 
©  Distracted  change;  and 


e  Recursive  Benchmarking^'^. 


•  CopyngMAMavVWsloniM?  AN  Riqms  Reserved 


Benchmarking 

-f  Benchmarking  is  no  longer  confined  in 
scope  and  attention  to  metrics  and  metrics 
objects. 

■f  If  Benchmarking  is  seen  as  solely  metrics  it 
is  the  cause  of  significant  resistance. 

♦  Benchmarking  is  the  ‘reach-ouf  activity  of 
comparing  yourself  and  your  organisation 
against  others. 


eCopynomAlisiMrWaaenIM?  M  RigMs  Reserved 
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4  Types  of  Benchmarking 

o  Process  Benchmarking; 

X'Work  Processes  &  Operating  Systems 

>-Most  Effective  Operating  Practices 

>=■  Increased  Performance  &  Bottom  Line  Results 

0  Performance  Benchmarking; 

>’Assessment  of  Competitive  Position 
J-Widely  Used  in  Business  and  SPl  e  g.  FPA 


©  Strategic  Benchmarking;  and 

>>  Examining  How  Others  Compete 
>'Cross-lndustry  Strategies,  Strucnires  &  Processes 
Requires  Considerable  Investment 
>•  Produces  Significant  Results 

o  Recursive  Benchmarking'’"'^. 

©CopyngMAlistarWMws  1997  AJi RigMs Reserved 


IS 


7  Levels  of  Benchmarking 

-m  o  Learning  from  Past  Successes; 

©  ‘Borrowing’  Good  Ideas; 

Best  in  Organisation; 
o  Industry  Standard; 

0  Industry  Leadership; 

0  Best  in  Country  Leadership;  and 
e  World  Class  Leadership. 


pCopyrxiM  Akslae  Waflers  1997  AH  RigMs  Reserved 
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Recursive  Benchmarking 


TM 


WCL 


•f  Recursive  Benchmarking  is  a  set  of 
tools,  processes  and  corrective  interventions 
to  assist  with 

•  Measuring  Change; 

•  Mapping  &  Modelling  Change; 

•  Initiating  Change; 

•  Driving  Change;  and 

•  Improving  the  Process  of  Changing. 

eCopyngMAMta*WM«n  1M7  AM RqtNs ReMtvM  17 


Applications  and  Benefits  of 
Recursive  Benchmarking™ 

♦  Setting  &  Refining  Strategy; 

B  ♦  Reengineering  Work  &  Business  Processes; 

■f  Problem  Solving; 

4-  Education  &  Idea  Enrichment; 

■f  Market  Performance  Comparisons; 

•f  Catalyst  for  Change;  and 

♦  Reduction  of  Overt  and  Covert  Resistance. 

CCopyngM  AtotaeWadm  1997  AM  R9MS  Reserved  18 
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How  Recursive  Benchmarking™ 
Reduces  Resistance 

♦  It  acts  as  an  example  of  the  processes  that 
the  organisation  is  seeking  to  adopt. 

♦  It  ‘opens  up’  individuals  and  teams  by 
involving  them  at  an  early  stage. 

♦  It  ‘sets  up’  individuals  and  teams  to  accept 
change  as  positive  and  to  integrate  it. 

eCopynBM AlstMWMmiM?  All RgMs Rmwvm  19 


WCL 


Conclusion. 

>  Recursive  Benchmarking^'^ 

•  Is  one  of  a  number  of  tools  that  can  be  used  to 
drive  the  cultural  changes  and  learning  that  are 
required  for  a  successful  implementation  of 
SPI. 


•  Provides  business  driven  quantitative  and 
qualitative  metrics  data. 

•  Is  a  method  for  increasing  organisational 
learning  and  changing  the  change  process  itself 


WCL 


OCopyngMAIM»tfWsll«f3  1997  AH  RiQMa  Rcs«fve<f  20 
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A  Co-ordinated  Approach  to 
Identifying  Software  Development 
Risk  in  MoD  Projects 


EuropMA  SEPC  *§7  •  1 


DGRA 


( 


( 


i 


— 

Speakers 


i 


•  Llewelyn  Jones  I 

Ministry  of  Defence  (PE),  Abbey  Wood,  Bristol,  UK  I 

phone;  +44117  91  3349$  I 

fax;  +44117  91  33917  I  4 

email;  isis42b@pe.mod.uk  I 


•  John  Hamilton 

Defence  Evaluation  &  Research  Agency,  Malvern,  UK 
phone;  +44  1684  896292 

fax:  +  44  1684  895616 

email:  jmhamilton@sec.dra.hmg.gb 
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The  Problem 


House  of  Commons  Defence  Committee 
Concerns 

Difficulty  in  Evaluating  Software  Bids 

-  iioftware  characteristics 

•  lack  of  visibility 

•  intangible 

Process  method  required  to  identify  risks 


Curopsan  SePG*f7-S 
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Process 


•  ‘...the  integration  of  people,  procedures  and  methods,  equipment 
and  tools  to  produce  the  desired  end  result...’ 


Procedures  and  methods 


SCE 


•  ‘...ind«pend«nt  team 
evaluation  of  an 
organisation's  sofbeare 
process...’ 

•  ‘...using  the  CMM...’ 

•  ‘...in  the  context  of  a 
particular  acquisition...’ 


Preparation 

Site  visit  to  each  supplier 

-  Personnel  interviews 

-  Document  reviews 

Analysis  and  reporting 


European  SEPG  *$7  •  7 
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Sampling 


Team  determine: 

-  Which  projects  to  review 

-  Which  KPAs  to  assess 

-  Which  goafs  to  rate 

-  Which  topics  to  probe 

-  Which  staff  io  interview 


European  $CPO’t7-t 
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Method  Selection 
and  Enhancement 


EuropMfi  SC»Gf7-f 


DGRA 


Selection 

Process  orientated  method  required 

Investigation  of  available  techniques 

-  non-proprietary 

-  supported 

-  track  record 

-  evaluation  technique 

CMM  and  SCE  selected  for  further 
investigation 


CuropMnSCPO*f7-10 
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UK  Trial  of  SCE  Method 


•  Aim 

-  to  establish  applicability  within  UK 

-  3  volunteering  UK  Defence  contractors 

-  feedback  soiicited 

•  Successful  outcome 

-  required  live  application 


EurofMM  SEPG‘f7-11 
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Pilot  SCE 

•  Major  UK  procurement 

•  Three  consortia  bidding 

•  Three  software  subcontractors  visited 

•  SEI  Involvement 

•  Team  of  6 

•  Five  weeks  of  effort 


■ 


Curope«*S€PG*fr-13 
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Lessons  Learned 

•  Data  collection  successful 

•  Company  cooperation  good 

•  Team  composition  significant 

•  Management  of  expectations  important 

•  Need  for  UK  Training 


EurepMn  $CP0‘t7-1S 


DGRA 


Enhancements 

•  Not  used  routinely  on  all  projects 

-  risk  primary  decision  driver 

•  Reduce  disruption  on  bidding  companies 

-  short-listed  contractors  only 

•  More  context  specific 

-  context  domain  experience 

-  project  specific  risks  form  input 


M 
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Risk  focus 


Re-use  of  Results 

•  Re-use  of  previous  SCE  encouraged 

-  previous  results 

-  elapsed  time 

-  similar  product  attributes/requirements 

-  boundaries  of  SEPG  organisation 

•  But  only 

-  with  bidding  company’s  consent 


European  8EPO  *§7  -  IS 


DeRA 


Thursday  18  |unc 
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Benefits 


EuropMn  S£PG  '•7  •  1* 


DGRA 


Benefits  to  MoD 

•  Addresses  original  concern 

-  forms  an  input  to  contractor  selection 
process 

•  Well-defined  method  for  identifying  and  managing 
software  process  risks 

•  Method  provides  in-depth,  reliable,  repeatable 
information  with  audit  b’aii 

•  Consistent  with  MoD’s  established  use  of  Pre- 
Contract  Award  Evaluations  (PCAE) 


DeRA 


Thursday  18  |unc 
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Policy  Promulgation 


Chief  of  Defence 
Procurement 
Instructions  TECH/490 


Defence  Procurement 
Management  Guide 
TECH/490 


Poicy 

instruction 


Detailed 

Guidance 


European  SEPG  ‘97  •  23 


Guidance  material 


CMM  &  SCE  overview 

Selection  criteria 

When  to  use 

Planning 

Tailoring 

ITT  preparation 

Team  selection 


Training 

Briefing  of  bidders 

Performing  evaluation 

Use  of  results 

Learning  from 
experience 

Documentation  & 
training 


European  SEPG  '97  >  24 
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DERA  focus 

•  Provision  of: 

-  Advice  to  MoO  project  managers 

-  Qualified  Evaluators 

-  Team  Leadership 

-  SCE  and  CMM  Training 

-  Expertise  in  process  assessment  and  supplier 
capability  determination 

-  Consistency  in  evaluation 


European  SEPG  *97  •  2S 


DGRA 


MoD  focus 

•  Point  of  contact  between  DERA  and 
MoD(PE) 

•  Infrastructure 

-  lessons  learned 

-  feedback 

-  continuity 

•  Maintain  SEI  liaison 


European  SEP6  '97  •  29 


DGRA 
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O  IHOMSON-CSF 

TTM  /SOFTWARE  AND  SYSTEMS  DEPARTMENT 

Five  years  experience  in  SPI: 
iessons  learned 


European  SEPG'97  ■ 

Amsterdam  -  juin  1997  j 

; 

TTM  /SOFTWARE  AND  SYSTEMS  DEPARTMENT 


Agenda 


•  The  Thomson-CSF  Contejft 

•  The  Thomson-CSF  maturity  profile 

•  SPI  at  corporate  level 

•  Experience  and  assets  sharing 

•  Improvement  results 


C  THOMSON-CSF 


TTM  /SOFTWARE  AND  SYSTEMS  DEPARTMENT 
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ConMHd«t«d  ravtntiM  (IMS):  US  1 7.2  bilion 
EmployM*  (at  31  Doc.  IfM):  44.300 


ConaoHdatad  ravafiuaa  (ItM):  US  1 7.4  biWon 
Emptoyaaa  (at  31  dac.  1H0):  40.500 


SOFTWARE  is  one  of  the  main  (and 
increasing)  added  values  in  our  systems 
(between  I37tt  and  90%  of  the  total  of 
our  principal  projects). 

More  than  5000  software  engineers. 

O  THOMSON-CSF 
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Software  Intensive  System  trends 


— ATC  -Q— Nabworks  -a— Simulators  ->*—031  Frontradar  — i — NCS 

I _ —iBaaa _ ] 

3S00  i  KCftti . /■  ’vi 


Every  S  years,  mean  size  is  xS  Co  xIO 

i84  CuR'^lSOoCVSCI) 

Thomaon-CSF  figuraa 


/ 

NCS  • 


■a, 

-V  y 


“^on(  rrJar  1 


88  90  92 
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The  Thomson-CSF  corporate  actions 


Human  resources 

Training:  IFGL 

(I  nnntiig  liistilutL'  for  Sl\' 
t-ngllliVnilg):  1987 

Management  of  the 
software  population: 

iii<iiplmcs  iiiiJ 

functions  1993 


Software  Develoitment  Process 
SPICE-Th  (•):  1992 


(')  (r«m  aa<sPC6 1 


Methodology  and 
Tools 

ATGL  (THOMSON  SIV 
engttu'enng  dcvehpnu’/it 

vfivironment):  1991 

RDL  (SofhiH2  rr 
Pitylopnient  Rcji'n'me 

Si/sffni);  1990 

MCPA  (Method  for  managing 
proposals  and  programs): 

Stabilized  in  1993 

MISTfSt/strm  engineering 
Method):1993 
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The  Thomson-CSF  organization  for  SW 

CEO 


Software  Engineering  CET  (*) 


(*)  Common  Efficloncy  Toam 
(Q)  SEPGs  at  ENTERPRISE  or  Business  Unit  level 

O  THOMSON-CSF  TTM  /SOFTWARE  AND  SYSTEMS  DEPARTMENT 
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The  Thomson-CSF  maturity  profile  | 

Matun 

int 

70  T 

SO 

M  ■ 

40  - 

M 

20 

10  • 

ty  profile 

•• 

H 

s  repan 

U 

i 

iition  (December  96)  ! 

_  1 

■  SEI  data  base  | 

1  1  Thomson-CSF  (%  per  unit)  1 

^  i 

11  1 

^ - - -  1.6  0  0,4  0  ^ 

1 

Mean  time  1 

2 

o  reach  a  U 

SEI  (Avr  96) 

2  4 

>vel  (in  months) 

Thomson-CSF  (Dec.  96): 

betwssn  asssssments 

•  1 

Thomson-CSF  (Dec.  96);  | 

Stntsgic  plan  to  2nd  istasa.  £ 

Level  1— *-2 

27 

35  ( 28  - ►  48) 

29  “ 

Level  2— *■  3 

25 

17* 

*  Estimate  ar>d  actual 

h 

17*  1 

1  ^  THOMSON*CSF  nM/SOrrvVAREANDSYSTEMSOEPARTMENT  | 

•  Most  of  the  time,  formalization  of 
the  estimation  practices  (costs, 
schedule  and  sizing 
parameters... at  the  domain  level): 

•  Remaining  cases  with 
weaknesses  on  System 
Requirements  Allocated  to  SW. 

commitment  on  a  concurrent 
definition...; 

•  For  some  Units,  responsibilization 
of  the  SW  Project  Manager  (PM)  & 
a  synthetic  commitment: 

•  A  trend  where  too  much 
delegation  on  work  products  audit 
by  SQA. 


A  corporate  guideline  that  defines 
the  process  and  methods. 

+  awareness  of  the  best 
examples: 

•  Focus  on  the  System  Eng. 
process  or  simple  formalization  of 
the  RM  process.. 

*  a  simple  commitment  form 
between  PM  &  SW  PM; 

•  A  focus  on  involvement  of  the  SW 
PM  in  Syst.  &  SW  spec.  (&  the 
benefits)  +  the  commitment  form; 

•  Focus  on  the  task  of  tracking  the 
raised  action  items . 


1 


Difficulties  for  level  2 
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Difficulties  for  level  3 


•  Generalization  of  Pa«r 
Reviews, 

❖  tailoring  when  Req. 
unstability, 

❖  former  practices  on 
document  reviews: 

e  Keep  the  data-base  simple; 

e  Tailoring, 

which  approach. 

❖  difficulty  to  think  "risks" 
and  "efficiency"...! 

small  projects. 


•  A  lot  of  tfsining  sessions  & 
some  benchmarks, 

■>  core  specifications  and 
design, 

■>  several  types  (high  & 
low  ); 

•  concrete  assessed  example: 
e  A  continuous  focus  with, 

■>  a  current  working  group. 

■O-  the  company  assets 

catalog. 
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SPI  at  corporate  level:  SPICE-Th  11 


93-94  Process  Action  Teams  (PAT) 


After  #  10  months  for  PAT, 
I  3  months  for  designing  a 
corporate  training  module 
for  each 


O  THOMSON-CSF 
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SPI  at  corporate  level:  training  by  Campus-Th 

Presently  14  courses  (#  one  day.  across  both  level  2  43),  ^  ^ 

Understanding  the  level  (2  or  3), 

❖  Conducting  an  SPI, 

■>  Requirement  Management  &  Engineering, 

4-  Advanced  Planning  4  Tracking,  Managing  Risks. 

700  students 

SW  Estimation  4  Capitalization.  Capitalization  4  SPI.  (1996) 

❖  SW  Subcontract  Management, 

■>  SCM  process, 

■>  SW  products/systems  engineering.  SW  tests  4  verification, 

0-  Peer  Reviews, 

❖  Teamworking.  ’ 


•  SW  Project  Management,  SQA  (Courses  with  mentoring). 

O  THOMSON-CSF 


300  students  (1996) 
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SPI  at  corporate  level:  SPICE-Th  III  (1/^ 


Goals  :  •  minimize  guides  writing/rewriting  costs 
-  speed  up  the  dissemination  process 

•  shorten  the  time  to  reach  level  3 

•  insure  that  guidelines  are  closer  to  the  field 
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tx> 


An  aneument  procasa  based  on  a  poo<  of  50  experienced  team  members, 
_ with  2  Thomson-CSF  and  2  US  SEI  authoriaed  "lead  assessors". _ 

O  THOMSON-eSF  TTW  /SOFTWARE  AND  SYSTEMS  DEPARTMEN 
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GDL  10>2^ 

CDLI2(IUq.*trt«nl)oS^2'  ^ 

I  GPtyWlQiflXtMw) 


P"Krt»» 


■i-asSIfeSifflitgas 


I  Kr  brochure  RDL 
RDL  101 
RDL  103.  104 
Training  support  IFGL 


Training 


Toob 


ATGL  GDL  200 
GDL  32 
GDL  50*1 
GDL  60 

ATGL  loots  manuals 
GDL  205 


(•)  •<>  Muh  ihi‘  usfr  hriH-huri'  is  not  u giuJi.'.  hnwewni  is  IwaivJ  umkr  'iratmn):’'  hs-iuusc  of 

ii\  cJiuuiional  qiialit}- 
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Experience  and  assets  sharing 


•  SPIN-Th  meets  every  month,  the  topics  are  planned  for  several  | 

months,  based  on;  | 

4- the  needs  of  SEPGs  (regular  survey  by  the  chairman),  I 

■❖•the  assets  catalog,  I 

I 

■❖•  the  recent  reach  of  a  level  by  a  Unit;  | 

•  The  assets  catalog  is  filled  at  the  end  of  each  assessment,  by  the  | 

members  of  the  team;  there  are  other  opportunities;  | 

•  The  Standard  Reference  System  and  the  assets  catalog  are  j 

electronically  available  on  an  internal  server.  | 


O  THOMSON-CSF 


TTM  /SOFTWARE  AND  SYSTEMS  DEPARTMENT 


_ Getting  to  level  2  benefits  (1/2) _ 

-  . 

I 

•  {Program/Project  Managers  and  Senior  Managers)  "we  have  a  | 

better  visibility  of  what's  going  on  in  the  SW  project",  f 

g 

...Project  Managers  analyse  the  indicators...,  1 

I 

•  Easier  commitment  with  the  customer  for  major  changes  in  the  * 

contract,  | 

S 

b 

^file  of  rationales...,  * 

•  (SW  Project  Managers)  "we  feel  completely  responsible  of  the  | 

SW  part",  ? 

14. 

w 

5 

•  "better  stabilization  of  the  baselines";  I 
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_ Getting  to  level  2  benefits  (2/2) _ 

- —  .I, .11-  ,  ,  —  I  ^ 

3 

•  A  mean  improvement  of  17  %  of  Cost  Performance  Index  in  2  years.  | 

while  reaching  level  2  (measured  on  3  Units;  #  800  Sw  eng  );  | 

•  Several  Units  where  the  Schedule  Performance  Index,  I 

improve  from  60  %  to  5  %,  | 

% 

<>-and  concurrently,  for  example;  I 

I 

A  l«v«l  2  Business  Unit  ^ 


20% 

10% 

0% 


Coat  Perfownice  lodti 


Mma  dtlay  bMnd  actMOite  (mofNhs)  Ad*  praducflvty  (1.0CA)) 


•  *  a  project  with  no  detect  at  acceptance 


H. 

I 
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_ Getting  to  level  3  benefits  (1/2) _ 

-  ■  -  - .  .  ■  ■  -  . - 1.  ■  -  ■  1 1  ■  I  • 

e  Getting  to  level  3;  I 

I 

❖  in  one  domain  (2  major  projects  with  #  100  persons  each),  | 

°  no  over  costs,  g 

°  in  time  acceptance  (with  no  defects  found),  | 

°  high  customer  satisfaction.  | 

s 

^  rapid  staffing  examples,  | 

•  +  180  persons  within  2  years,  including  s 

% 

•  +  100  persons  within  10  months;  I 

u. 

willingness  not  only  of  the  SW  managers  (larger  buy-in  among  \ 

the  SW  developers).  | 

'0 
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Getting  to  level  3  benefits  (2/2) 


•  PR  benefits:  for  a  level  3  Unit,  cost  of  defect  detection 
and  correction  4  time  less  if  done  before  any  tests,  with 

^^an  efficiency  of  50  %  and, 

^a  benefit  of  12  %  on  SW  development  costs  (when  80 
%  PR  on  code); 

•  ROI.  getting  to  level  2:  this  Unit  has  worked  out  a  ROI 
of  3.6  to  1. 
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— M  The  Company _ 

Digital  Equipment  Corporation 

•  Digital  is  a  world-wide 
supplier  of  computer 
solutions. . .  hardware, 
software,  networks,  and 
services 

•  Corporate  headquarters  in 
Maynard,  Massachusetts 

•  66K  employees  world-wide 

http://www.digital.com 


t  Oi^Ul  Eqwpmenl  CorporatioB  1997 
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i 


« 


d  I  g  I  tlail 


The  Site 


Digital  Equipment  Digital  Equipment 

Corporation,  Inc.  Company,  Ltd. 
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The  Organisation 


Integrated  Office  Services  Group 


•  -  60  engineering  staff 

•  Part  of  a  3-site  (110- 
person)  organisation  in 
England,  the  US,  and 
Ireland 

•  Responsible  for  groupware 
products 

•  Experienced  in  large  scale 
integration  projects 


A  Digital  E^vipmnU  Corporation  1997 


d  r  g  r (jal) 


The  Major  Product 


ALL-IN-1 

A 

•  Multi-function  integrated 

office  system 

•  Size; 

-  >10K  modules 

\ 

-  >2.5M  high-level  LOG 

V 

-  2-3K  changes  per  release 

•  Installed  base  of  5  million 

users 

V 

•  Evolved  from  timeshared  to 

client-server 

X  A 


ALL-IN-1 

Server 


ALUN-1 

Time-«hared 
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Problems 


•  Major  software  release 
has  significant  problems 

•  Software  builds  out  of 
control 

•  Classic  chaotic 
organisation 

•  Need  for  improvement 
seen  by  management 
staff  and  engineers 


C>  OigiUl  Eqaipaieat  CorporaboD  1997 


Instability 


Defects 


ggmf  The  Improvement  Effort 


•  First  Phase  (1988-1992) 

-  not  oriented  around  any 
particular  methodology 

•  Second  Phase  (1992-1996) 

-  guided  by  Capability 
Maturity  Model  (CMM) 
and  self-assessment 
process 

•  Significant  corporate 
restructuring  and  downsizing 
during  this  period 


y'  Optiaimmt 

^  Manafrd  j  4 

/ 

Drfiard  |  3 

Initial  (1) 

RepealaMc  2  ^ 

First  Phase 


Second  Phase 
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SEI  CMM  Assessment  Results 


1993  Assessment 

•  At  Initial  level  with  some  projects  running  at  the 
Repeatable  level.  Some  processes  in  place  for 
Defined  level. 

1996  Assessment 

•  At  Defined  level. 


mam  Comparing  Projects 

•  Diamond 

•  Sapphire 

-  24  month  project 

-  1 8  month  project 

-  50  engineers 

-  1 7  engineers 

-  22  failures 

-  2  failures 

-  484  r^submissions 

-  93  resubmissions 

-  20%  rework 

-  1 3%  rework 

-  2931  days  of  rework 

-  565  days  of  rework 

C  Di^Ul  Eq«ip««at  Corporation  1997 
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Developers  on  ALL-IN-1 


Single  to  Multi-Product 
Responsibilities 


•  Increased  span  of  product  responsibilities 

•  Bandwidth  to  exploit  new  opportunities 

•  Increased  capacity  for  survival 


C  OiglUl  Cmparatioa  1997 


Topics 


•  Background 

•  Results 

•  Assessment  Strategy 

•  Learnings  and  Experiences 

•  Next  Steps 

•  Questions 


e  Digiul  &|«ipaiMi  Cerpmstinm  1997 


Assessment  Strategy 


•  Targeted  high-visibility  projects  only 

•  Cross-functional  assessment  team 

•  Two  distinct  functional  group  types 

-  development  engineers 

-  others 

•  Aimed  for  100%  participation 

•  Expectation  of  24  month  cycle 


C  DlglUl  Corporalim  1997 
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jgpj  Assessment  Experiences 


•  Hard  work! 

•  Requires  investment.  .  .  management  support 

•  Expectations  must  be  set  realistically 

•  Training  essential  for  everybody 

•  Some  interpretation  and  tailoring  required 

•  New  assessment  technique  is  better 


O  Di^Ul  E<|«ip«eat  CovporatiM  1997 


Post-Assessment 

mmm  Experiences _ 

•  Commitment  requires  constant  reinforcement 

•  Effective  change  management  is  critical 

•  Must  treat  improvement  as  a  bona-fide  project(s) 

•  Dealing  with  organisations  at  the  Initial  level  can  be 
frustrating 

•  Need  to  manage  the  management  line 

•  Results  have  wholly  justified  investment 
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Most  “bang  for  the  buck 


•  Formal  configuration 
management 

•  Regular  cross-project 
reviews 

•  Better  integration  of 
quality  assurance 

•  Formal  reviews 

•  Statistics  publication 

•  Document  and  process 
templates 

•  Base-level  planning 

C  Digital  E<| Corpoeatten  1997 
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Topics 


•  Background 

•  Results 

•  Assessment  Strategy 

•  Learnings  and  Experiences 

•  Next  Steps 

•  Questions 


C  Digital  E^vipaieal  Corporatioii  1997 
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Next  Steps 


•  Implement  actions  from  ‘96 
assessment 

•  More  extensive  use  of 
metrics  for  continuous 
improvement 

•  ISO  9001  /  TickIT 
registration 

•  Assist  partner  groups 


e  DigiUl  CarporaboB  1997 
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Summary 


•  Improved  customer 
confidence 

•  Improved  productivity 

•  Greater  predictability 

•  Improved  communications 

•  Higher  group  morale 

•  Catalyst  for  change 


PmfomancB 
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A  Case  Study  of  CMM  Software 
Process  Improvement  at  Digital 

Questions  ??? 


C  Digital  Eqaipwaat  CovporalioB  1997 


Scfgio  Bdndinclli  &  Alvaro  Sanz  Monastcrio,  ESI 


The  Compiementary  Aspecti  of 
Process  Capability  and  Reuse  Capability 


The  complementary  aspects  of 
process  capability  and  reuse 
capability 

Sergio  Bandinelli 
Sergio.Bandinelli@e8i.es 

European  SEPG 
June  19, 1997 


E-S£P6«7-  t 

1 

1 

Overview 

*  Product-line  engineering 

• 

ROADS  project 

• 

ROADS  preliminary  results 

• 

ROADS  lessons  learned 

• 

Reuse  and  process  capability 

• 

R-SPICE  and  SPLICE  models 

e-SEPG'97—2 

OES/ 1997 

Thursday  19  (une 
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The  Complefnentary  Aspects  oi 
Process  Capability  and  Reuse  Capability 


Product-line  engineering 

•  A  product-line  is  a  collection  of  (existing 
and  potential)  products  that  addresses  a 
coherent  business  area  or  domain. 

■  Product-line  engineering  is  concerned 
with  the  efficient  development  of  a 
product-line  that  delivers  high  quality 
products  tailored  to  the  specific  needs  of 
each  customer. 


E.SEPG-97-3  eESM997 
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Transtioning  to  product-line  engineering 

One  of-a-kind  “a".y  of-a-kind 

•family  view 
•assembly-line  style 

•  Changes  required 

•  to  the  development  process 

•  to  the  organisation 

•  Management  commitment  is  essential 
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The  Complementary  Aspects  ol 
Process  Capability  and  Reuse  Capability 


The  experience  of  ROADS 

•  ROADS:  Reuse  Oriented  Approach  for 
Domain  based  Software 

•  Partners: 

•  Thomson-CSF 

•  European  Software  institute  (ESI) 

•  Prosperity  Heights  Software  (PHS) 

•  PIE  (Process  Improvement  Experience) 
under  the  ^*"^1  programme. 

e-sfPcs7-7  ©Eatwr 


Four  pilot  experiments 

•  Air  traffic  control 

*  decrease  time-to-market  to  1/3  of  current. 

•  Control  and  command  of  short  range  air 
defence  systems. 

«  improve  the  reliability 

•  Training  simulators 

*  Obtain  significant  reduction  of  costs 

•  T raffic  Management  (planning  of  traffic) 

*  Improve  the  flexibility  and  robustness 

c-scpew-»  eesiim 
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The  CompIrmenUfy  Aspects  ol 
Prfxress  Capabilily  and  Reuse  Capability 
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Project  baseline 

•  Diagnosis  of  current  situation 

*  to  evaluate  potential  profitabiliy 

*  to  understand  existing  strengths  and 
weaknesses  in  the  organisation 

*  to  set  the  appropriate  priorities 

■  Issues  considered: 

*  domain  potential 

*  organisation’s  reuse  capability 
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Incremental  approach 

•  Each  increment  involves  performing 
domain  engineering  activities  that  bring 
support  to  projects 


*  Typical  increment  time:  3  months 


Perform 

increment 


Plan  increment 


Review  increment 
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The  CcHiiplefnefiUry  Aspects  ol 
Process  Capability  and  Reuse  Capability 


Assessment  experience 

-  Reuse  capability  assessment  using  RCM. 

*  Domain  potential  assessment  using  DAM 

*  Assessment  characteristics 

•  Self-assessments  (3  to  8  persons  in 
assessment  team,  incl.  facilitator) 

•  One  day  duration 

•  Results  presented  in  the  form  of  profiles 
and  assessment  findings 


Assessment  results 

•  Adaptation  introduced  to  RCM  and  DAM 

*  Duration  reduced 

*  Translation  to  French 

*  Graphical  representation  of  profiles 
changed. 

*  Modification  of  rating  scale 

•  Participation  of  key  business 

development  experts  turned  out  to  be 
essential  in  the  successful  development 
of  assessments _ 


Thursday  19  |unc 


(C407b)  S* 


.■sjiixsirc  I  lav.U^.4:. 

Benefits  to  the  Bummss 


.Vtoy«i,  turup«siii  cu(itiiu»:»tuo 


Sergio  leiMtincHi  li  Alvaro  Sana  Monastcrio,  {SI 


The  Complcflicfilary  Aspects  at 
Process  Capability  and  Reuse  Capability 


Preliminary  improvement  results 

•  Identification  of  new  opportunities  for 
improvement. 

•  Creation  of  awareness  in  ttie  organisation  of  the 
range  of  applications  it  is  capable  of  building  by 
capitalising  of  past  project  experience. 

•  Initial  support  to  projects:  e.g.,  additional  support 
for  negotiating  and  setting  new  contracts  or  to 
support  decision  on  whether  to  bid  for  a  contract 
or  not 
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Lessons  learned 

•  Reuse  adoption  requires  some  level  of  process 
maturity. 

•  Established  processes  are  much  difficult  to 
change. 

•  Difficulties  and  resistance  encountered  when  the 
reuse  adoption  programme  follows  other  quality 
improvement  actions  (such  as  obtaining  ISO 
9000,  achieving  a  certain  CMM  level,  etc.). 
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Process  Capability  and  Reuse  Capability 
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Reuse  and  process  capability 

*  Process  capability:  is  the  ability  of  a  process  to 
achieve  a  required  goal. 

*  Product-line  capability:  is  the  ability  of  an 
organisation  to  deliver  products  that  satisfy 
specific  customer  needs,  using  a  common 
domain-specific  support  of  tailorable  processes 
and  assets. 

*  Domain  reuse  potential:  is  a  measure  of  the 
potential  of  profitability  from  applying  reuse  in  a 
domain  (intended  as  a  business  area). 
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Synergy  between  reuse  capability  and  process 
capability 


Process  a 
capability  f 


LEVEL  5 
LEVEL  4 


Synergic  growing  of  process 
and  product-line  capability 


LEVEL  3 
LEVEL  2 
LEVEL  1 


STAGE  1  STAGE  2 


Product-line 
►  capability 

STAGE  3 
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1  he  Complementary  Aspects  of 
Process  CepebilMy  end  Reuse  Capability 
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Assessment  models 

*  R-SPICE:  an  extended  SPICE  process  capability 
model  enriched  with  a  new  product-line  process 
category. 

*  SPLICE  (Staged  Product-Line  Capability 
Evaluation):  a  staged  model  for  transitioning  to 
product-line  engineering. 

*  D/.M:  a  domain  assessment  model. 
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The  SPICE  Reference  Model 
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The  CompiemenUry  Asipetls  o( 
Process  Opability  and  Reuse  Capability 


Preliminary  set  of  LIN  processes  in 
R-SPICE 

•  LIN.1  Manage  the  product-line 

•  LIN.2  Define  the  product-line 

•  LIN.3  Engineer  the  product-line 

•  LIN.4  Define  product-line  production 
process 

•  LIN.5  Provide  project  support 
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The  Compieiiiefitary  AspctU  oi 
Froce^s  Capabilitv  and  Reu&e  Capability 


The  SPLICE  model 

*  The  SPLICE  model  identifies  a  set  of 
stages  in  the  transition  to  product-line 
engineering. 

■  Each  SPLICE  stage 

*  corresponds  to  one  coherent  set  of  goals 
and  practices  to  achieve  those  goals 

•  constitutes  a  step  in  the  direction  of 
product-line  engineering. 
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R-SPICE  process  dimension  and  product 
line  capability 


0  12  3 

- ^ 

Product  -  line  capability  stages 


I  I  Customer  H  Support  H  Organisation 
H  Product-line  H  Management  H  Engineering 
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The  Complementary  .\spiH  ts  oi 
Process  Capability  arul  Reuse  C  .kpobtlity 


Conclusions  and  future  work 

•  Preliminary  results  on  experiences  about 
transitioning  to  product-line  engineering 

•  Capability  models  support  this  transition 

•  Next  steps: 

•  Build  consensus 

•  Further  develop  models  and  explore 
synergy 

•  Validate,  validate,  validate... 
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Software  8c*t  Practice: 
BencTiti  to  the  Busineu 


A  Strategic  Challenge  for  Europe 


Software  Best  Practice 


Making  use  of  the  best  practices 
in  management  and  software 
engineering  methods  and 
technoiogy 


The  European  Conimh^on~DGn.  ITPrograame. 


Quality  and  Community  Policies  I 


•  Industrial  Policy 

Industrial  Competitiveness 

•  Internal  Market 

Free  movement  of  goods 

and  services  (in  particular) 


The  European  Commiasion  -DGIU.  IT  Programme. 
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So<tw4rc  ■«(  Practice 
Benefits  to  ific  Business 


Quality  and  Competitiveness  (in 


•Quality:  Critical  in 

gaining  an  increased 
competitive  edge 


•  A  lot  remains  to  be  done 


77m  European  Commiaaton  •  DG  HI.  IT  Programme. 


Actors  in  SBP  I 


•  Economic  operators 

Main  responsibility 

•  European  Union 

Facilitator  overall  favorable 

economic  environment 

AWARENESS  POLICY 
SUPPORTING  IMPROVEMENT 

•  National  Activities 


The  European  Commiaalon~DG  IH.  IT  Programme. 
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bonwaie  Best  Practice: 
Benefits  loihe  Busmest 


Best  Practice.  Critical?  I 


CREDIT  CARD 


-  55,000  cards  issued 

-  People  queuing 

to  get  100  Guilders  fO( 
free 


The  Buropmn  ConmMon^  OG  IK.  IT  Prognmme. 
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Different  Business 

'A  Environments  Require 

—  a 

£;  Different  Priorities 

L! 

m  The  European  ContmMcn-OGIK.  IT  Progrmmme.  1 
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Scficfits  to  the  Buiinws 


Different  Priorities 


BUSINESS  DRIVER 

•  Time  to  market 

XIOSBANK 

20%  consumer  credit 

CLAAS 

5  MECU  sales  boost 

•  Safety /Reliability 

B&K 

7S%  less  error  reports 

The  Buro$MUi  Commim»ion-OG  IH.  IT  Prognmm. 


Case  Studies  I 


5  CASE  STUDIES 

SHOWING  BUSINESS  BENERTS 

FROM  THE  ESPRIT  INITIATIVE  ESSI 


The  BiropmnConwriealon  •OGIH.it  Programme. 
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Quality  vs  Process 


CUSTOMER  SATISFACTION 


QUALITY 
IMPROVEMENT 


•  PROCESS 
IMPROVEMENT 


BUSINESS  NEEDS 


Cas0  studlM  show  correlation 
BAK  7S%  error  reduction 
Surveys  show  correlation 
IBM  survey 
HOWEVER. 

this  is  a  statistical  truth 
unless . 

DRIVEN  BY  BUSINESS  NEEDS 


The  European  CommtMton  •  06  W.  /T  Frogremme. 


What  is  actually  done  ? 


Is  SBP  a  Big  Issue  for  you? 

Indeed !! 

What  do  you  actually  do?  Little  ? 

•  Any  practical  activities? 
process  improvement,  education,...? 
e.g.  53%  of  Irish  companies  have  no  QMS  (Fortwn  1995) 
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Software  Best  Practice: 
Benefits  for  the  Business 


The  purpose  of  this  paper  is  to  show  the  substantial  and  quantifiable  business  benefits  to  be 
gained  from  adopting  Software  Best  Practice. 

This  paper  arose  from  a  study  of  a  number  of  Software  Best  Practice  projects  which  have  been 
carried  out  over  the  last  two  years  in  different  types  of  organisations  with  a  variety  of  different 
goals.  This  means  that  the  information  relates  to  "real-life"  case  studies. 


±fiere  are  two  Siisiness  •messages,  one  for  companies  using  software  in  their 
procCucts  or  in  their  Business  support  systems,  “the  clients",  and  one  for  "their 
providers"  (either  software  companies  or  intemaf  informatic  departments).  In 
other  words,  hey  messages  for  the  vast  majority  of  Businesses  in  ‘Europe. 


Th  e  messaue  for  "the  providers"  is  that  Software  Best  Practice  has  proved  that  productivity. 

quality,  customer  satisfaction,  and  speed  of  deliverv'  can  he  significantly  improved  through  ^ 

Software  Best  Practice. 

The  message  for  "the  clients"  is  that  the  software  supplier's  professionalism  will  materially 
affect  the  quality,  the  timeliness  and  the  cost  of  what  is  delivered.  Clients  should,  in  their  own 
interest,  monitor  their  suppliers  and  determine  the  level  of  professional  software  engineering 
employed.  i 

This  paper  focuses  on  case  studies.  In  every  one  of  them  a  modest  investment  in  adopting 
Software  Best  Practice  principles  to  improve  software  engineering  practices  has  produced 


significant  business  benefits.  Fore.xample; 

•  at  BBV,  the  largest  Spanish  bank,  migration  of  applications  programs  to  a  new  platform  was 
6,5  times  more  efficient; 

•  at  Briiel  &  Kjaer,  a  Danish  manufacturer  of  high  precision  instruments,  systematic  unit 
testing  reduced  the  number  of  errors  in  products  released  to  the  market  by  75%; 

•  at  CDC.  a  major  French  public  finance  company,  software  maintenance  cost  is  being 
reduced  by  50%; 

•  at  Claas.  Europe's  largest  manufacturer  of  harvest  machinery,  better  specification  and 
software  management  brought  a  significant  product  enhancement  to  market  a  year  early, 
boosting  sales  by  at  lea.st  5  Million  FCTE 

•  at  ENEL,  the  world's  second  largest  electricity  supplier,  a  formal  specification  method 
reduced  project  development  cost  by  1 8%; 


Company 

Result 

BBV 

6.5  times  more 
efficient  migration. 

B&K 

75%  less  errors  in 
released  products. 

CDC 

50%  reduction  in 
maintenance  cost. 

Claas 

5  Million  Ecu 
sales  boost. 

ENEL 

1 8%  cost  reduction. 

Engineering 

60%  improvement  in 
accuracy. 

"The  good 
news  is  clear 
business 
benefits’* 
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at  Engineering,  a  software  company,  a  professional  approach  to  estimating  project  costs, 
effort,  duration,  etc,  impro\  ed  the  accuracy  of  their  estimating  by  60%. 


In  each  case,  not  only  have  the  efficiency  and  quality  of  software  production  and  maintenance 
improved,  the  real  good  news  is  that  there  have  been  clear  business  benefits.  In  seven  of  the 
cases  the  competitiveness  of  the  company  as  a  whole  has  been  materially  uplifted.  In  five 
cases,  close  attention  to  the  specification  and  communication  of  requirements  has  enriched 
customer  satisfaction  and  customer-supplier  relationships.  In  four  cases,  the  company's  quality 
image  has  improved.  In  another  two.  the  high  profile  success  achieved  through  improved 
software  engineering  has  substantially  developed  senior  management's  appreciation  of  what 
Information  Technology  can  do  for  its  business. 

Recent  studies  performed  by  a  number  of  well  known  organi.sations  confirm  the  business 
benefits  gained  through  Software  Best  Practice.  Among  others,  it  is  worth  mentioning  an 
IBM(l)  survey  of  36.3  European  companies  from  different  sectors,  reports  published  by  the 
ESl(-)  (European  Software  Institute)  and  the  paper  published  by  Ovuml^)  based  on  experience 
drawn  from  the  European  Software  and  Systems  Initiative  (ESSI) 

Note  should  be  taken  of  the  general  trend 
observed  in  the  World  Competitiveness  Report 
(sketched  in  Fig  1)  concerning  the  use  of 
Quality  Management.  The  USA  are 
progressing.  Europe  is  progressing  but  at  a 
slower  rate  and  a  regression  is  observed  in 
Japan.  Europe  still  has  much  business  benefit 
to  gain. 

This  paper  identifies  the  potential  benefits  in 
the  field  of  software  best  practice.  Neither  the 
software  engineering  approaches  it  describes 
nor  the  nature  of  the  benefits  achieved  are 
peculiar  to  the  individual  companies  discussed.  Their  experience  indicates  that,  by  intelligent 
use  of  the  large  repertoire  of  management  methods  and  software  tools  available,  any  software 
development  operation  (whether  in  a  software  company  or  in-house  in  a  user)  can  make 
significant  improvements  in  what  it  delivers,  in  how  soon  it  delivers  it.  in  its  cost  of  delivery, 
and  above  all,  in  its  customers’  satisfaction.  To  achieve  this  requires  leadership  and 
professionalism.  No  software  developing  company  can  afford  to  ignore  this  finding. 


(It  (2).  (3i  References  can  he  found  in  the  annexes. 
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Case  Study  2 


Case  Study  3 


Specification  and  Software  Management 
Rethoight 

“5  Million  Ecu  Boost  to  sales” 

Claas  KCiaA  and  their  software  supplier.  Miiller-ldektronik, 
radical  l\  re\ised  their  processes  for  drawing  up  and 
communicating  requirement  specifications  and  for 
implementation  management.  Claas's  product  came  to  market  a 
year  earlier  as  a  result,  well  before  any  direct  competition,  and 
is  likely  to  bring  in  5  MHCU  ^  of  sales  in  that  year. 
Management  understanding  of  the  business  contribution  of 
electronics  has  leapt  forward. 


Efficient  Migration  of  Applications 
Sixfold  Productivity  Gain  ” 

PROFit  Gestion  Informatica  S.A.  offers  a  serv  ice  for  converting 
software  from  one  environment  to  another.  By  using  software 
engineering  techniques  to  analyse  the  suitability  of  application 
for  conversion  -  recommending  redevelopment  of  the 
application  where  it  was  not  suitable  -  and  to  semi-automate  the 
conversion  process,  they  were  able  to  improve  their  productiv  ity 
from  one  programme  converted  per  week  to  6.5.  and  also  to 
improve  post-conversion  maintenance  productivity  by  at  least 
10%. 


Introduction  of  Configuration  Management 
“Gaining  a  Competitive  Edge” 

By  introducing  configuration  management  into  the  development 
process  of  their  financial  application  products.  Datamat 
Ingegneria  dei  Sistemi  S.p.A.  vastly  decreased  the  time-to- 
market  and  the  number  of  errors  in  their  software  products.  The 
overall  effect  was  to  decrease  development  costs  in  order  for 
Datamat  to  gain  a  competitive  edge. 
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Case  Study  4 


Case  Study  5 


Case  Study  6 


Case  Study  7 


Case  Study  8 


Formal  Specification  Method 
“t/p  to  18%  Cost  Reduction” 

After  mtroducing  a  formal  specillcation  method  into  their 
software  development  process,  ENEL  has  experimented  a 
reduction  of  the  overall  development  effort  (18%)  and  an 
increment  of  the  company  outsourced  control  system. 

Improved  project  estimation 

”60%  reduction  in  average  project  estimation  errors  ” 
Engineering  Ingegneria  Informatiea  S.p.A.  succeeded  in 
improving  the  accuracy  of  their  project  estimation  (manpower, 
cost  and  elapsed  time)  through  improving  their  software 
engineering.  This  was  achieved  by  building  a  database 
compiling  their  experience  gained  in  earlier  projects.  The  result 
was  to  reduce  the  average  estimation  error  from  25%  to  8%. 


A  Fresh  Start  with  New  IT  Technologies 

”10%  in  Overall  Company  Costs  Savings” 

By  using  innovative  software  engineering  techniques  and  taking 
advantage  of  the  new  IT  and  Communication  technologies. 
RACE  ASISTENCIA  has  been  able  to  build  a  brand  new 
integrated  service  system  to  support  their  mother  company's 
core  business.  While  cutting  the  Software  Development  costs  by 
20%,  the  new  system  also  reduces  by  10%  the  cost  of  the 
company  main  business  operations. 


Tackling  Quality  Management 

” Drastic  Reduction  in  Maintenance  Cost” 

By  adopting  new  tools  for  Quality  measurement  of  software 
projects  and  Quality  improvement  of  existing  applications. 
Informatique  CDC  has  achieved  an  important  reduction  in 
maintenance  costs  (up  to  50%  cost  decrease)  and  gain  in 
productivity  (5-10%)  and  has  increased  the  motivation  of  the 
software  development  work  force. 

Establishing  when  the  Bugs  Occur 

” Reducing  Bugs  in  Released  Systems  by  75%)  ” 

By  introducing  systematic  unit  testing  procedures  to  verify  the 
software  (some  80%  of  the  added  value  in  their  products),  Briiel 
&  Kjaer  was  able  to  reduce  the  number  of  error  reports  by  75% 
in  the  new  version  of  an  electronic  measurement  product. 


Thursday  19  |une 


(C407C)  P  -  5 


l:uropean  Lommi!»!!i(on 


UvUciii)  io  t/tr 


Case  Study  9 


Case  Study  10 


Case  Study  11 


Case  Study  12 


Case  Study  13 


Tackling  the  Documentation  Headache 

"10-20%  Performed  Improvement  as  a  Consequence" 

By  implementing  a  rational  documentation  system,  accordingly 
to  company'  needs.  VBI  has  achieved  10%  schedule  reduction 
and  18%  budget  savings.  VBI  has  shown  that  small  projects  can 
be  documented  without  adding  overheads. 

Quality  control  systems  change  the  way 

SOFTWARE  IS  DEVELOPED 
"Achieving  ISO-9000  certification  " 

Due  to  customer  demand  the  company  has  made  software 
quality'  an  integral  part  of  the  development  lifecycle  and 
significantly  changed  the  way  in  which  customer  releases  are 
approved. 

Object  oriented  design  reduced  testing  time 

"Changing  the  software  development  process  ” 

After  adopting  an  object  oriented  design  methodology,  the 
company  have  reduced  the  amount  of  time  required  for  testing 
and  provided  greater  opportunities  for  code  re-use. 


Experimenting  changes  the  development  process 

"40%  Schedule  &  Effort  reduction  ” 

After  experimenting  with  object-oriented  technology  the 
Regional  Government  Services  group  with  IT  Tieto  Oy  have 
implemented  a  working  system  to  ensure  take-up  of  new 
technologies  through  the  rest  of  the  group. 

Adoption  of  Knowledge  Modelling  Methodology 

"Using  a  methodology  to  gain  ISO900I,  wins  new 
business  ” 

By  adopting  a  methodology  to  record  knowledge  elicited  for  the 
development  of  knowledge  based  software  systems,  the 
artificial  intelligence  section  of  Rolls-Royce  and  Associates 
have  been  able  to  achieve  ISO900I  certification  in  an  area 
without  established  methodologies.  This  has  won  them  new 
contracts  with  their  major  customer. 
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Annexes 


A.  References 


i 


(1)  Ensuring  profitable  investment  in  software  process  improvement.  IBM.  1996. 

(2)  Software  Engineering  Practices  in  Europe  1995 

(3)  Best  Practice  in  software  development.  Ovum.  1996. 


B.  Useful  organisations 


In  examining  your  software  proees.ses  you  may  find  the  following  organisations  of  use. 
mans  organi.se  conferenees.  seminars  and  workshops  on  a  t  ariet>  of  related  topics. 

ESSf:  Software  Best  Practice 

'I'he  FiSSI  office 
F'iuropean  Commission 

DGIII  R  (N105  3/43).  rue  de  la  Loi  200.  B-1049  Brussels 
e-mail:  essi'ddg3. cec.be 
fax:  +32  2  2%  83  64 

European  Software  Institute,  Spain 

http: /'wvvAv.esi.es 


Software  Engineerin';  Institute  (SEI),  Carnegie  Mellon  University,  US 

http: '''www.sei.cmu.edu 

Software  Process  Improvement  Networks 
http:  '\vww. sei.cmu.edu/spins.html 

Bootstrap  Institute 

Pasi  Kuvaja  +358  852  05  399 

h  ttp : ' 'WWW .  i  o  1 .  ie/- i  sc  n/homepages/bootstrap/i  ndex  .htm  1 
SPICE 

http:  "wwxv-sqi.cit.gu. edu.au/spicc 
http,  'www.compita.co.uk 

European  Software  Process  Improvement  Foundation 

http:  vvww.espi.co.uk 
*44  (0)  1908  630500 

National  Computer  Societies 

British  Computer  Society  (BCS)  Software  Process  Improvement  Network  (I'K) 
Brian  Chatters  bw. chatters  a  man0523.wins.icl.eo.uk 
*44  (0)  161  2.30  5718 
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